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ABSTRACT 


Organizational Maintenance Activities (OMAs) within the Naval Aviation Mainte¬ 
nance organization do not have an adequate information system (IS). This seriously 
degrades their ability to efficiently and effectively manage their aircraft, equipment, and 
personnel. Information systems to support both Naval Air Systems Command 
(NAVAIR) and the operational chain of command include Naval Aviation Depot In¬ 
formation System (NADIS), Naval Air Logistics Data Analysis (NALDA), and Naval 
Aviation Logistics Command Management Information System (NALCOMIS). The 
portion of NALCOMIS intended to support OMAs is not scheduled to be fully imple¬ 
mented until 1999. Decisions made at OMAs have an immediate impact on force read¬ 
iness and mission capability. .Moreover, the largest unfulfilled need for information 
systems in the naval aAiatiflu community is at the OMAs. This thesis examinei.the . 
histor\' ofl^ in .Aviation .Maintenance, analyzes why O.M.As lack adequate' ISs, and of¬ 
fers a solution within the current technological capabilities of the aviation maintenance 
community. The potential improvement in operational readiness, avoidance of increased 


maintenance and personnel costs, improved decision making, and accuracy of informa- 
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I. INTRODUCTION 


A. BACKGROUND 

Over the years a large organization has developed in the Nasy dedicated to 
procuring aircraft, repairing those aircraft, ensuring the parts and associated 
aeronautical equipment are purchased to repair them, and managing the repair 
effort. Today, the Naval Air Systems Command (NAVAIR) encompasses every 
aspect of a\iation in the Navy, from research and development, through pro¬ 
curement, to maintenance and servicing. NAVAIR, the Naval Supply Systems 
Command (NAVSUP), and various operational and administrative commanders 
constantly interact to ensure that operational readiness standards are designed 
into and maintained throughout the life cycle of each aircraft weapons system. 
Measuring and tracking operational readiness requires data and information 
about maintenance, logistics, and operations. Maintenance information includes 
data about the status of the aircraft and about what maintenance has been per¬ 
formed to achieve that status. Logistics information includes data about the lo¬ 
cation and estimated time of arrival of parts, personnel, and equipment. 
Operations information includes data about the flights flown and the missions 
performed by those units. This information forms the basis of future procure¬ 
ments (e.g., aircraft, spare parts, and people), current repair policies (i.e., fix it 
or scrap it), parts inventory stocking (i.e., how many and where), as well as which 
unit or aircraft to use for which mission and whom to assign to a particular 
maintenance action. 
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All aspects of Naval Aviation Maintenance are governed by the Naval Avi¬ 
ation Maintenance Program (NAMP) which was established by the Chief of 
Naval Operations (CNO) on 26 October 1959. The details of this program are 
promulgated in OPNAVINST 4790.2E [Ref. 1] which specifies the "policies, pro¬ 
cedures, and responsibilities for the conduct of the NAMP at all levels of main¬ 
tenance throughout naval aviation." 

The NAMP is a dynamic program intended to take advantage of improve¬ 
ments in both technological and management methods and techniques. Infor¬ 
mation system technology has benefited from improvements in computer 
hardware technology, and Aviation Maintenance has taken ad\antage of those 
improvements to increase the capabilities of its hardware. However, information 
systems are not just hardware, but software and people as well. Software devel¬ 
opment is the acknowledged weak link in information systems de\elopment. 
"Computer hardware productivity continues to increase by leaps and bounds, 
while software productivity seems to be barely holding its own." [Ref. 2: p. 43] 
This has led to an estimated backlog of three to five years [Ref. 3: p. 323] which 
DeMarco says is "the fault of inflated and unreasonable expectations." [Ref. 4: p. 
4] Naval A\iation has fallen \ictim to the same inflated expectations and poor 
software production problems described by Boehm and DeMarco. The most de¬ 
ficient aspect has been in the information system capability and support of Or¬ 
ganizational Maintenance Activities (OMAs). OMAs are typically limited to a 
few micro computers, some office automation software such as wordproccssing, 
spreadsheet and database management, and maybe a terminal linking them to 
their immediate support acti\'ities. 
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B. OBJECTIVES 


The objective of this thesis is to start the process of providing OMAs with a 
much needed information system (IS). As with all such systems, the first step is 
a plan derived from an analysis of the information requirements of the OMAs. 
The key goal of the system is to provide the information required to the people 
who require it when they require it and in such a form that they can and will use 
it. It is more than just automation. It is a blueprint for long and short range 
system development. It will allow system growth to be managed rather than 
merely accepted by default. Current and planned information systems are in¬ 
cluded where warranted or dictated by NAVAIR policy. Se\eral issues will be 
addressed, including: 

• What are the strategic goals and missions of OMAs?, 

• What information is required to achieve those goals?, 

• Which, if any. current or planned systems should be included?, 

• What interfaces with other systems should h included?, 

• Should an Expert System (or several) be an integral part of the plan?, 

• Should a Decision Support System (or several) be an integral part of the 
plan?, 

• Who, i.e. what activity, should coordinate implementing this plan?. 

• Who should be tasked with actual development?, 

• W^ho should be tasked with post deployment support of the system?, and 

• How will this plan be funded? 

C. SCOPE, LIMITATIONS AND ASSUMPTIONS 

The proposed system is so large that this thesis will be able to address only 
design issues. The plan will include a proposal for the subsequent steps necessary 
for full implementation. 
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Descriptions of DMAs are based on the author's personal experience at two 
types of OMA, an Operations Maintenance Division and a Naval Aircraft 
Squadron, as well as on descriptions found in the literature. l 

Four four key assumptions of this thesis are that the Naval Aviation Logistics 
Command Management Information System for OMAs (NALCOMIS OMA, or ” | 

NALCOMIS Phase HI) will not be implemented for several years [Ref. 5; pp. 

13-14], that there is no interim alternative planned, that for the foreseeable future 
Organizational Maintenance Activities will continue to be without sufficient in¬ 
formation systems capability to make the best possible use of their assets in 
meeting CNO operational readiness and safety goals, and finally that an interface 
between the proposed system (called OASIS), and NALCOMIS will be required. 

I 

D. RESEARCH METHODOLOGY 

Research into the current status of Navy systems, both fielded and under i 

i 

0 1 

development, was conducted both in the literature and by telephone converse- 
tions with NAVAIR Program Manager Air 270 (PMA-270), NAVAIR code 
41142F (Air-41142F), Naval Sea Logistics Center code 612.2 

(NAVSEALOGCEN-612.2), Navy Management Systems Support Office code 
51 (NAVMASSO-51), and Naval Aviation Maintenance Office code 02 
(NAMO-02). Initial intentions to continue the work of McCaffrey [Ref. 6] and i 

Allen & McSw'ain [Ref. 7] in the area of Expert and Decision Support Systems 
were overcome by the need for an overall information systems plan. Extensive 
telephone conversations between the author and NAMO 02 commencing in Au¬ 
gust 1989 confirmed this need. * 
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E. THESIS ORGANIZATION 


The remaining chapters of this thesis are as follows; 

II. Aviation Maintenance Organization. A general description of how the 
Naval Aviation Community is organized, with emphasis on the OMA and its 
role. 

III. Information Systems. Definitions of different information systems, a 
brief history of information systems, areas of current emphasis in information 
systems, and a description of information systems in NAVAIR. 

IV. Proposed Information System, OASIS. A brief discussion of strategic 
goals and functions, a review of NALCOMIS functions and modules, a de¬ 
scription of the proposed OASIS modules, and a prop'^sed implementation 
plan. 

V. Recommendations, Further Research, and Conclusions. Recommen¬ 
dations about implementing OASIS, a discussion of areas needing further re¬ 
search, and conclusions. 
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II. AVIATION MAINTENANCE ORGANIZATION 

A. THREE LEVELS OF MAINTENANCE 

Aircraft maintenance in the Navy is separated into three levels, Organiza¬ 
tional, Intermediate, and Depot. NAVAIR described the three levels in the Naval 
Aviation Maintenance and Material Management Manual [Ke^. 8]. Organizational 
maintenance refers "to those maintenance functions normally performed by an 
operating unit in support of its own operations." [Ref. 8; p. 1-4] The most com¬ 
mon Organizational Maintenance Activity (OMA) is a squadron which is as¬ 
signed a specific number of aircraft and people with which to perform its 
mission(s). Intermediate maintenance refers "to those maintenance functions 
normally performed in centrally located facilities." [Ref. 8: p. 1-5] Intermediate 
Maintenance Activities (IMAs) typically support several operating units repres¬ 
enting several different types of aircraft (e.g., E-2, F-14, A-6, F/A-18). Depot 
maintenance refers to maintenance functions performed in "industrial-type es¬ 
tablishments," [Ref. 8: p. 1-6] known today as Naval Aviation Depots (NADEPs). 
The most common of these functions is the overhaul, where an aircraft is taken 
apart, inspected, and reassembled with new or reworked parts. 

The three levels of maintenance are based on the resources av ailable at the 
activity (e.g., technical ability, facilities, and equipment). Maintenance functions 
arc assigned to each activity by matching the resources required to perform the 
particular function with those available at the activity. For each type of aircraft. 
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the details of this breakdown of maintenance functions is developed during pro¬ 
curement and specified in the Maintenance Plan for that aircraft. 

The maintenance plan establishes and delineates the repairable compo¬ 
nents and maintenance requirements of a selected system or item of equip¬ 
ment. For each repairable component, the maintenance plan identifies the 
maintenance level authorized to perform the maintenance action indicated, 
and estimates the frequency of component failure or repair action. [Ref. 9: 
p.5-4] 

There is no special relationship among OMAs, IMAs, and NADEPS other 
than that specified by their respective maintenance levels and unique capabilities. 
Any IMA is allowed to provide support to any OMA if it has the capability. 
Similarly, any NADEP is allowed to provide support to any IMA or OMA if it 
has the capability. Note that not all 0-level> capabilities are assigned to all 
OMAs; nor all l-le\el capabilities to all IMAs; nor all D-level capabilities to all 
NADEPS. Each activity has its own assigned capabilities. For example, aerial 
refueling stores (ARS) are o\'erhauled at NADEP Alameda, which has been as¬ 
signed responsibility for all ARS. 

OMAs are the operating units. They are the most mobile and consequently 
the least well equipped to perform major repairs. IMAs are located in major 
shore stations and aboard large ships, i.e.. naval air stations & aircraft carriers, 
and ha\c more in-depth repair capabilities than OMAs. There are six NADEPs. 
all located in the continental United Slates (CONUS). They all have the basic 
capabilities of an industrial manufacturing facility, as well as specific responsi¬ 
bility for various types of aircraft and equipment. 


I "-level" refers to the maintenance level normally associated with a particular maintenance 
capability--0-lcvel to organizational capabilities, 1-lcvel to intermediate, and D-lcvel to depot, l or 
example, replacing the wheel assembly on an aircraft is considered an ()-level capability, but re¬ 
placing the actu;d tire on that same wheel assembly is normally an 1-levcl capability. 
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B. AVIATION MAINTENANCE PRINCIPLES 


The Naval Aviation Maintenance and Material Management Manual [Ref. 8] 
prescribed "procedures for the management of aircraft maintenance and material 
at organizational and intermediate levels of maintenance." [Ref. 8: p. I-l] Spe¬ 
cifically described are two broad areas of aircraft maintenance—a Planned 
Maintenance System (PMS), and a Maintenance Data Collection System 
(MDCS) [Ref. 8: p. I-l]. The stated objective of these systems was to "insure the 
highest state of aircraft readiness and reliability at the lowest cost in men, money, 
and material." [Ref. 8: p. 1-3] The Naval Aviation Maintenance and Material 
Management Manual [Ref. 8] of 1967 has become OPNAVINST 4790.2E [Ref. 
1] of 1989, but the objecti\e is still "to achieve and continually improxe aviation 
material readiness and safety standards established by the Chief of Naval Oper¬ 
ations (CNO), with optimum use of manpower, material and funds." [Ref. 9: p. 
2 - 1 ] 

The Planned Maintenance System is a system similar to that pro\ided by 
automobile manufacturers to their customers. The PMS is derived from the 
maintenance plan for that aircraft, and specifies that certain maintenance actions 
be performed at pre-determined intervals to ensure safe and efficient operation 
of the aircraft over its entire planned lifez. 

Used by OMAs, IMAs, and NADEPs, the Maintenance Data Collection 
System is a system for collecting data about every maintenance action performed 

2 Ilic term "scheduled maintenance" refers to those actions performed at the prescribed inter¬ 
vals. "Unscheduled maintenance" refers to those "unplanned" maintenance actions perfomied w hen 
something breaks or doesn't work as intended. 
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on an aircraft or component of an aircraft. It also provides for collecting data 
about parts used, man-hours expended, and flight operations completed. 

The Naval Aviation Maintenance and Material Management Manual [KeL 8] 
also put forth two principles to ensure that the stated objective was met. Those 
principles are still applied today. First is the principle of "LOWEST LEVEL 
MAINTENANCE". This principle requires "that all aircraft maintenance be 
performed at the lowest possible leveP." [Ref. 8: p. 1-6] Application of this prin¬ 
ciple must be tempered by "optimum economic use of resources." [Ref. 9 p. 2-1] 
For example, buying a million dollar set of test equipment for every OMA if each 
OMA will use it only a few times a year is not an optimum use of resources. In¬ 
stead. one such set should be bought, installed at an IMA, and used by the IMA 
to perform the required tests for several OMAs. 

Second is the principle of "MANAGEMENT BY EXCEPTION". This 
means "that actions or incidents which vary markedly from certain standards or 
norms arc singled out or 'excepted' from the whole for special management at¬ 
tention." [Ref. 8: p. 1-6] The Naval Oil Analysis Program (NO.AP) is a clear 
application of this principle. Oil samples arc taken from components (mostly 
engines) and analyzed for traces of various metals. Depending on what metal 
and how much of it are present in the sample, certain actions arc dictated. These 
actions range from just taking another sample to removing and replacing the 
component. This same principle is applied in a more macro sense to OM.^s. 
Higher authorities won't interfere with the way an OMA is performing its mission 
unless the statistics reported about that OMA's performance and readiness bc- 

3 1 he lowest level is the 0.\IA, with the IM,\ and NADI P being progressively higlier levels. 
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come an exception either to an established norm or to that OMA's own past re¬ 
cord. 

In short, the PMS specifies the minimum maintenance that must be done—the 
scheduled maintenance; the exception and lowest level principles cover the rest-- 
the unscheduled maintenance; and the MDS records the data that describe all the 
actions pertaining to aircraft. 

C. ORGANIZATIONAL MAINTENANCE ACTIVITY 

The Maintenance Department of an OMA is made up of sexeral work cen¬ 
ters, each of which specializes in performing a particular type of maintenance. 
For example, the powerplants work center will generally work on the aircraft en¬ 
gine and fuel systems. In the maintenance department, having aircraft ready to 
fly as published in the daily flight schedule is the dominating criterion for per¬ 
forming maintenance on aircraft. Coordinating all the efforts required to satisfy 
that daily flight schedule is a herculean task performed by the most experienced 
and senior enlisted personnel available, usually referred to as Maintenance Con¬ 
trol Chiefs (MCCs). They work in a work center called, not surprisingly. Main¬ 
tenance Control (MC). Figure 1 on page 11 is a diagram of the functional 
relationships within an OMA Maintenance Department. 

In addition to meeting the daily flight schedule, MCCs attempt to satisfy all 
the requirements of all higher authorities, as well as plan for all known future 


4 This diagram is slightly different from the normal 'organization chart" for an OMA. where 
MC is just another work center |Ref 10; pp.3-3,3-61. 1 his reflects the fact that Maintenance Con¬ 
trol .MUST control ALL aspects of the daily maintenance effort. The most obvious reason for this 
requirement is safety—having electrically activated hydraulic surfaces unexpectedly close on some¬ 
one performing maintenance can be prevented when MC is in control because MC would know 
not to allow electncal p>owcr on that aircraft. 
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Maintenance Officer 



Figure I. OMA Maintenance Department Functional Relationships 

Adapted from [Ref. 10 ; p. 3-3] 

missions. Higher authority requirements are specified in \arious instructions in¬ 
cluding OPNAVINST 4790.2E [Ref. I], Fleet. Type and Functional Commander 
instructions, squadron instructions and maintenance department instructions. 

The MCCs typically manage the minute to minute maintenance, making de¬ 
cisions about which aircraft to repair, whom to assign to make the repair, and 
when to actually do so. Many factors enter into these decisions, including worker 
e.xperience and training, as ailability of parts, a\ ailability of tools, sufficient time 
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to accomplish the repair, other demands on technicians, and the criticality of the 
specific repair to the OMA's immediate and long range missions. 

Long range strategic maintenance planning is managed by the 
Maintenance/Material Control Officer, and, in those squadrons fortunate enough 
to have one, a senior Master Chief Petty Officer, known as the Maintenance 
Chief. In those OMAs without a Maintenance Chief, his function is performed 
by the most senior and/or experienced MCC available. Strategic planning in¬ 
cludes such issues as: 

• determining what mix of airplanes, people, and equipment to take on the 
next detachment/deployment, 

• coordinating with an IMA or NADEP for aircraft repairs beyond the au¬ 
thorized capability of the OMA itself, 

• deciding which Technical Directives (TDs) to incorporate in which aircraft, 
and when to do so, 

• deciding what changes to make to the maintenance schedule to ha\e enough 
aircraft available to take on the next detachment. 

The quantity of information required to plan and accomplish both the minute 
to minute missions and the long range ones is quite large. Knowledge of c\cry 
maintenance program, all governing instructions, each piece of equipment, and 
the abilities and availability of both people and equipment, as well as knowledge 
of every system in the aircraft are some of the key elements that must be factored 
into every decision. Add the one constant in aviation maintenance—change—and 
the possibilities are staggering. Aviation maintenance has done as well as it has 
for so long ONLY because the quality of the people in these critical MCC posi¬ 
tions has been so high. 
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How much better could OMAs do if information systems were at their dis¬ 
posal? This question has been partially answered by McCaffrey [Ref. 6], Allen 
[Ref. 11], and Allen & Mcswain [Ref. 7] in their theses. These authors analyzed 
the benefits of improved OMA information systems in their particular area of 
interest-expert systems, NALCOMIS, and decision support systems respectively. 
The systems they proposed were not intended to be a complete OMA information 
system. Their proposals represent a portion of OASIS, and should be integrated 
with OASIS to form one overall Information System specifically aimed at OMA 
missions and goals. 

D. INFORMATION USERS IN AVIATION MAINTENANCE 

Many people have a legitimate need for information about na\al aviation, 
from those in\olved in direct aircraft maintenance at the OMA level, through the 
\arious chains-of-command, on up to the President and Congress. The demand 
for information has grown as the number, complexity and required administrative 
support of aircraft has grown. An example of the growth in demand for infor¬ 
mation is Congressional demand for reports from the Department of Defense, 
which grew by 2000 percent between 1970 and 1988 [Ref. 12]. Although not 
specific to Na\'al Aviation, this example is indicati\ e of the growth in demand for 
information in general. 

Information at an OMA falls in two categorics-internal and external. 
Internal information is information intended for use within the activity to achieve 
its goals and perform its missions, whereas external information is information 
generated solely to .satisfy a requirement imposed from outside the aciixiiy and 
has no \alue within the activity itself. This distinction docs not preclude acti\ iiies 
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from using information originally intended for others, i.e., an OMA using read¬ 
iness information required by its operational commander, or an operational 
commander requiring information primarily intended for use by the OMA. In¬ 
stead, the distinction will help in assigning priorities to the information require¬ 
ments of OMAs. 

An additional distinction must be made between data and information. Data 
are "raw facts in isolation....These isolated facts convey meaning but generally are 

not useful by themselves." [Ref. 13: p. 67] Information is 

...data that has been manipulated so it is useful to someone...Information 
must tell people something they don't already know or confirm something 
that they suspect. It should be noted that one person's information may be 
another person's data. [Ref. 13: p. 67] 

Implicit in these definitions is the fact that information in isolation is merely 
data and that a person is needed to attach meaning to information. Whether it 
be as routine as "John Doe is out sick today," or as sensitive as the most top secret 
intelligence, information has always been critical to managers and leaders. To¬ 
day, information has gained widespread recognition as a strategic resource as 
important as, if not more important than, physical assets [Refs. 14, 15 , and 16]. 

Within the OMA, the information users include virtually every person in the 
OMA, from the Commanding Officer (CO) and Executive Officer (XO), through 
ail the Department Heads, to the technicians repairing the aircraft. The CO 

wants to know what is happening in HIS activity. His questions include: 

• How many aircraft are ready to fly?, 

• How much money do we have left for fuel?, 

• How many people are on leave, in school, or going on the next detachment?. 

• What is the status of the inve.stigation of John Doc's accident?. 
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• How many pilots will need swim re-qualification during the next detachment 
or deployment? 

The Department Heads want to know the same things as the CO & XO, both 
to take care of problems before being asked for explanations, i.e., to give the CO 
& XO solutions rather than problems, and to better perform their own jobs. For 

example, the Maintenance Officer needs to know: 

• Will a particular aircraft be ready to fly tomorrow? next week? for deploy¬ 
ment?, 

• Are the parts needed for the next detachment pack-up ready, or will they 
be?, 

• Have the necessary schools been scheduled for technicians making the next 
deployment?, 

• Are enough tools on hand to perform required maintenance? 

In Maintenance Control all the same questions must be answered more fre¬ 
quently, as well as some more detailed ones. Examples are: 

• What inspections are due today? tomorrow? next week?, 

• When is the next major inspection due?, 

• Does Power Plants ha\e enough people trained to change three engines next 
week?, 

• How long will it take to change the radio in aircraft 510?, 

• Can supply get us a new radar receixer before the next aircraft launch, or 
do we take it out of another aircraft? 

• Has the daily inspection been completed on the aircraft next to launch? 

E. SUMMARY 

In summary, the naval aviation community can not perform its mission 
without the right information available to the right people when they need it. 
From the top planning and procurement level. NAVAIR, through the operational 
levels, to the lowest level of maintenance, the OMA, there arc manv users of in- 
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formation systems. Each of those users has his own requirements for both 
quantity, frequency and format of information. Information systems (ISs), the 
subject of the next chapter, are the tools used to satisfy those requirements. 
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III. INFORMATION SYSTEMS 


This chapter provides a general discourse of information systems (IS) and 
their history, a discussion of current emphasis areas on information systems rele¬ 
vant to OASIS (Organizational Activity Strategic Information System), including 
applicable development techniques and methods, and a review of information 
systems in axiation maintenance. 

The principle function of information systems is to get the right information 
to the right people at the right time in a form that they will use. Stoner and 
Wankel say that "Only with accurate and timely information can managers 
monitor progress toward their goals and turn plans into reality." [Ref. 17: p. 619] 
Implicit in these statements is that an information system MUST be focused on 
the goals of the organization. If not, the IS merely drains the organization's re¬ 
sources. An organization can not long survive, or in the case of an OMA. achiexe 
high readiness, by wasting resources such as capital assets, personnel time, man¬ 
agement attention, operating costs, and productixe effort on an IS that docs 
nothing to achiexe organizational goals. 

Information has four basic characteristics—quality, timeliness, quantity, and 
relexance. Information must accurately reflect the situation it purports to de¬ 
scribe, be in time for any necessary action to be undertaken, be of a quantity no 
more and no less than the manager needs or can process, and be relevant to that 
manager's organizational function [Ref. 17: pp. 620-621]. Any information sys¬ 
tem. to be of xalue to an organization, should emphasize these four character- 
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istics. This emphasis should start at the inception of an IS, continue through the 
design and implementation, and most importantly, be among the determining 
criteria for any "enhancements" added to the system during its life. 

An information system is just a tool. As with all tools, an IS can be misused, 
abused, not used, or, as intended, used effectively to achieve the goals of the or¬ 
ganization. Failure to keep the organization's goals and the characteristics of 
information in mind during IS development will virtually doom an information 
system to failure. 

Five categories of information systems are relevant to OASIS. They are 
transaction processing systems (TPSs), management information systems (MISs), 
management reporting systems (MRSs), decision support systems (DSSs). and 
expert systems (ESs). Each of these will be discussed in the following sections. 
The purpose will be to establish some working definitions, place each in a histor¬ 
ical perspecti\'e, add the current IS trends of relevance to OASIS, and finally to 
describe some applicable methods and techniques for development. 

A. DEFINITIONS 

I. Information Systems 

There are many definitions of information systems. In simplest terms, an 
information system is a means to get timely, usable information to the managers 
or the knowledge workersS who need the information. More formally: 

An information system is a subsystem of the business. Specifically it is a 
person machine arrangement of components that interact to support the op- 

5 Knowledge workers arc "...those people whose jobs involve the creation, processing, and 
distribution of information." |Rcf. 13: p. 4(tl 
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erational, managerial, and decision-making information needs of knowledge 
workers. [Ref. 13: p. 53] 

All the following categories of information systems fit within this broad defi¬ 
nition. The framework developed by Whitten, Bentley and Ho, Figure 2 on page 
20, is useful for keeping these systems in perspective relative to each other. This 
framework is also useful for identifying the principle knowledge-workers that 
utilize and benefit from each type of system. 

2. Transaction Processing Systems 

A transaction processing system (TPS) is a system to record, store and 
process data representing events important to an organization. The "aim of 
record-keeping systems is the processing of high volumes of data, not providing 
support for decision making." [Ref. 18: p. 446] Transaction processing systems 
"include payroll preparation, account management, and savings account interest 
tabulations." [Ref. 18: p. 446] A transaction processing system is the foundation 
of an information system. Without the data a TPS collects and stores, there can 
be no information. 

3. Management Information Systems 

A Management Information System is a system that pro\'ides manage¬ 
ment the information (not just data) they need, in the form they need it. in time 
for them to use that information to the benefit of the organization. MlSs arc 
typically used to aid managers in making those decisions that occur regularly, and 
for which there are pre-defined procedures or rules. An MIS is "an integrated 
system for pro\ iding information to support the planning, control and operations 
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Source: Whitten, Bentley and Ho [Ref. 13 : p. 79] 






of an organization." [Ref. 18: p. 498] A more rigorous and formal definition is 
that an MIS is: 

a formal method of making available to management the accurate and timely 
information necessary to facilitate the decision-making process and enable the 
organization's planning, control, and operational functions to be carried out 
effectively. [Ref. 17: p. 622] 

4. Management Reporting Systems 

Management reporting systems are systems which produce, at specified 
intervals, pre-defined reports based on the data collected and stored by its sup¬ 
porting TPS. There are three types or reports. The first is the detail report. This 
is simply a detailed listing of transactions recorded by the TPS. These arc useful 
for transaction verification. The second report is the summary report. This is. 
as the name implies, a summary of the details of transactions. Summary reports 
arc typically used to identify key items of interest to management, c.g.. sales, in¬ 
terest paid or earned, profit loss, or outstanding orders. The third type of report 
is the exception report. This is a report to which some preset conditions ha\c 
been applied as a filter, presenting the manager with onh the exceptions to his 
predefined rules (filters). An example of such a report is a list of in\entory items 
that are low and need to be ordered. [Ref. 13: pp. 71-73] A manager, by pre¬ 
defining the filter settings minimizes the time that must be spent manually filter¬ 
ing the data in order to obtain needed relevant information. 

5. Decision Support Systems 

Even though the term "decision support system" has been in use since the 
early 1970s. "there is still no strict definition of its meaning. For man\’ writers, 
DSS is a philosophy, a way to seek a useful complementarity between technolog- 
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ical tools and human judgment and discretion." [Ref. 19: p. v] Sprague and 
Carlson, in what is considered the classic DSS treatise, say that "DSS comprise 
a class of information system that draws on transaction processing systems and 
interacts with other parts of the overall information system to support the 
decision-makiiifc activities of managers and other knowledge workers in organ¬ 
izations." [Ref. 20: p. 9] Bennett says that "A DSS is a coherent system of 
computer-based technology (hardware, software, and supporting documentation) 
used by managers as an aid to their decision making in semistructurcd decision 
tasks." [Ref. 21: p. 1] Turban provides what he calls a "Working Definition" of 
DSS: 

A DSS is an interactive flexible and adaptable CBIS [Computer-based in¬ 
formation system] that utilizes decision rules, models and model base coupled 
with a comprehensi\e database and the decision maker's own insights, lead¬ 
ing to specific, implemcntable decisions in solving problems that would not 
be amenable to management science optimization models per se. Thus, a 
DSS support complex decision making and increase their effectiveness. [Ref. 
22: p. 73] 

AH of these definitions have two common threads. First is supporting the 
decision-maker in decision situations for which pre-defined procedures or rules 
do not exist or are incomplete, and second is improx ing the effectiveness of the 
decision-maker's decisions. A DSS is composed of three major subsystems, the 
Data Management Subsystem, the Model Management Subsystem, and the Di¬ 
alog Management Subsystem [Ref. 20: pp. 28-35). These are shown conceptually 
in Figure 3 on page 23. As DSSs arc one of the more recent dexelopments the_\’ 
are discussed in more detail in “2. Decision Support Systems" on page 33. 






Manager (User) 
and Tasks 


Figure 3. Conceptual model of Decision Support System 

Source: Turban figure 3.2 [Ref. 22 : p. 75] 

6. Expert Systems 

E.xperi systems (ES) are the latest t\pe of information system, to be em¬ 
braced by business organizations. An expert system is a computer based system 
used to consistently le\'erage the knowledge of an expert (or experts) to the ad- 
\antage of an organization, independent of access to the expcrt(s). Because it is 
the latest bandwagon, many authors haw jumped aboard, and definitions of ES 
abound. Turban says that: 
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Expert systems are computerized advisory programs that attempt to imitate 
or substitute the reasoning processes and knowledge of experts in sol\ing 
specific types of problems. [Ref. 22 : p. 321] 

Whitten, Bentley and Ho say that: 

In an expert system, the expertise and knowledge associated with decision 
making is stored in a knowledge base. Programs are written to access the 
knowledge bases and databases to identify and make decisions.... [Ref. 13: p. 
454] 

Walters and Nielsen even eschew the term "expert system" in favor of 
"Knowledge-based systems" about which they say: 

In the simplest of terms, the notion behind knowledge-based systems is to 
capture the problem-solving expertise of a human being—an expert in a highly 
constrained problem area, called a problem domain—and represent this per¬ 
son's knowledge or expertise in a computer in such a way that the computer 
can approximate the expert's abilitv to solve a particular class of problems. 
[Ref. 23: p. 4] 

An expert system is composed of three basic components. First is the 
knowledge base, made up of rules, heuristics and facts about the subject area. 
Second is the inference engine which contains the program with which the ES 
"reasons" and reaches a conclusion. Third arc the interfaces that connect the in¬ 
ference engine to the user, knowledge engineer, and the explanation subsystem. 
The knowledge engineer is the person who gathers the expert's knowledge and 
conv erts it to the form needed by the knowledge base. Figure 4 on page 26 shows 
the typical organization of a knowledge based system. The components in the 
Development Environment are the tools used by the knowledge engineer or sys¬ 
tem developers. The Delivery Environment is what will actually be the 
knowledge-based system delivered to the user. As with DSSs. additional dis- 
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cussion of the aspects of ESs relevant to OASIS can be found in “3. Expert 
Systems” on page 35. 

B. BRIEF HISTORY OF INFORMATION SYSTEMS 
1. The Business Focus 

Information Systems (ISs) have always existed in one form or another. 
They have been used to gather, retain, and use information about something of 
interest to the user. In early society, people retained information about basic 
necessities such as where to hunt, which animals to pursue, and which plants 
were safe to eat. People still, in their personal lives, practice storing and proc¬ 
essing information of interest to them. Libraries are another example of infor¬ 
mation gathering and storing. Today howe\er, with many such basic 
"information systems" taken for granted, the term "information system" has come 
to mean a business-oriented computer based system. 

The in\ention of the electronic computer in the 1950s brought a re\o- 
lution to information systems. In what is called the "Computer .^ge," [Ref. 25: 
pp. 2-3] the computer changed the way data was collected and used. Rooted in 
the manual accounting systems of business, computer-based accounting systems 
took o\er gathering the data needed by owners and managers to measure the 
performance of their businesses. Business owners and managers asked such 
questions as: 

• Were they making a profit?, 

• Was the profit as much as the previous day? week? month? year?. 

• Were their costs going up or down?. 

• Was there a trend in sales, up or down? 
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Figure 4. Anatomy of a Knowledge-based System 

Source; Carrico, et al, Figure 1-2 [Ref. 24 : p. 5] 

Computerized information systems, specifically accounting systems, pro\ ided an¬ 
swers, or the data from which answers could be dcri\ed. 

One of the key characteristics of these early information systems was; 


...their facility in dealing with well-structured and routine processes that 
computers can easily handle. The procedures may be repeated many times 
during the course of a day, week, or month. They are also well understood, 
to the extent that clearly specified procedures can be formulated. [Ref. IS; 
p. 446] 
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Since computers, with correct instructions, perform faster, more accurately, and 
more consistently than people, they were (and still are) used to perform the rou¬ 
tine functions of storing, sorting, and summarizing the data collected in these ac¬ 
counting systems. 

One of the reasons eomputers were accepted as information handling 
tools was the tremendous increase in the quantity of data being gathered, stored, 
and used. Manual information systems were unable to keep up. Entire computer 
systems had to be dedieated to the task of collecting data, manipulating that data 
in some fashion, and generating periodic reports based on the data. The systems 
built to perform these functions were, and still are called transaction processing 
systems (TPSs). 

Transaction processing systems started as manual systems, and many 
manual systems are still in use.^ The first computer based TPSs were frequently 
built simply to automate an existing manual system. Some people still think of 
TPSs as mere automatic manual systems. Senn. for example, says that "Trans¬ 
action processing systems substitute computer processing for manual record- 
keeping procedures." [Ref. 18: p. 446] 

In the 1960s and 1970s. as managers were inundated with rooms full of 
printed reports, they realized they were wasting their time trying to extract what 
they needed from those reports. What they really needed was information, not 
piles of data. Management information systems (MISs) were heralded as the 
solution to the data glut. MISs were made possible by a rapid impro\emcnt in 

6 Some organizations have ehosen, for cost, fear, simplicity, or some other reason, not to use 
eomputers. 
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computer technology and a growing knowledge of how to effectively apply that 
technology. In fact, advances in technology and knowledge made development 
of newer and better information systems inevitable. By their very name, man¬ 
agement information systems offered management the promise of real informa¬ 
tion. Recall that information is "data that has been manipulated so it is useful 
to someone." [Ref. 13: p. 67] Developed principally to satisfy the need to reduce 
the large quantity of data to usable information, management information sys¬ 
tems also allowed management to gain better control of the resources being ex¬ 
pended on TPSs, e.g., capital and personnel. 

Management Information Systems never fulfilled their promise. The 
"idea of building a single, integrated management information system (MIS) for 
any and all organizations...never really got off the ground." [Ref. 13: p. 116] In¬ 
stead, MISs frequently became just management reporting systems (MRSs), in 
reality, little more than a TPS with better report generating capability. One of 
the reasons MISs failed to become all they were intended was the inability of 
management to define their requirements, and then to stabilize those require¬ 
ments long enough for the MIS to be completed. Management's "information 
needs were so numerous, volatile, and diverse that it would take an enormous 
staff of analysts and programmers to fulfill." [Ref. 13: p. 116] This problem is 
not likely to change. Management's requirements are, of necessity, always 
changing to keep pace with their ever changing environment, and information 
systems must likewise change. 

Another problem with MISs, and in fact with many information systems 
of the 1960s and 1970s, was inflexibility. The internal workings of computers are 
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quite rigid. A computer's representation of "w" is not the same as that for "W". 
This type of distinction is basic to a computer's operation, and therefore implies 
that once a system was implemented and being used, it could be adapted to new 
requirements only by a huge expenditure of additional resources. Consequently, 
attempting to "apply a very rigid, unforgiving technology to a very flexible and 
often unpredictable business situation" [Ref. 13: p. 115] met with limited success. 
This failure is attributed to trying to satisfy the needs of an "open system" with 
a "closed system." "An open S 3 stem doesn't have well-defined interactions with 
its environment," whereas "A closed system has a precise number of well-defined 
inputs and outputs." [Ref. 13: p. 115] Since the application of a closed system 
solution to an open system problem didn't work well, another approach to using 
the technology was necessary. 

Further de\'elopments in available technology, both hardware and soft¬ 
ware. continued to occur, and decision support systems (DSSs) came into being. 
Whereas MISs were aimed at the routine, well-structured decisions of middle 
managers, "DSS are focused still higher in the organization." and more toward 
less well structured decision problems. [Ref. 20: p. 7] DSS arc " Dedicated to 
improNing the performance of knowledge workers in organizations through the 
application of information technology. " [Ref. 20 : p. 8] DSSs pros ide the user, 
manager, or knowledge-worker, with greater flexibility in data manipulation, and 
also extract data from various sources and generate reports on that data. In fact. 
DSS have added an "on demand" and "custom" report ability to the manipulating 
and reporting functions of TPSs & MISs. 
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2. Artificial Intelligence and Expert Systems 

While the business oriented TPS, MIS, and DSS were evolving, a parallel 
evolution was occurring. At a conference in 1956 at Dartmouth College, Artifi¬ 
cial Intelligence (AI) was "born." Artificial intelligence is "an umbrella term for 
a variety of fields of study that include robotics, cognitive science, vision systems, 
natural language understanding, sound recognition, and knowledge systems." 
[Ref. 24: p. 15] In spite of the similarity to humans, predictions that computers 
would be able to think and learn, and ultimately replace humans, proved pre¬ 
mature. In fact, only in the past decade has AI enjoyed any significant com¬ 
mercial success, and that has been primarily in the branch of AI called Expert 
Systems. A key distinction between the business oriented systems (TPS, MIS. 
MRS & DSS) and ES is the means by which each solves problems. The business 
oriented systems apply a pre-defined step-by-step procedure, called a "program," 
to a set of data and arrive at some resui . With ES, the procedure is not pre¬ 
defined. Rules, facts, and heuristics' are stored and invoked as necessarv or 
applicablc-not in any pre-defined specific order. The latter is actually the wav- 
humans think. We have stored a wealth of learned facts, experience-based 
heuristics, and known rules that we apply both to routine situations, such as 
driving a car, and to new situations, such as learning to drive a boat or an air¬ 
plane. Some recent examples of successful ES applications include; 

• an ES to generate "an hour-by-hour baking schedule", screen job applicants, 
and write labor schedules for Mrs. Fields, Inc. [Ref. 26: p. 1], 

" "Heuriuic.<;...aTc decision rules regarding how a problem should be solved. (Ref. 22: p 5a| 
They amount to "educated guesses" about the solution to a problem. 
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• Digital Equipment Corporation uses an ES (XCON) to customize the con¬ 
figuration of VAX and PDP-11 computers prior to manufacture. [Ref. 27, 
and 28], 

• an ES is being used to help solve the African food shortage through 
aquaculture-fish farming [Ref. 29; p. 57]. 

• using an ES to optimize the use of limited satellite launching resources [Ref. 
29: p. 58], and 

• using an ES to plan the refueling of NASA's space shuttle [Ref. 30]. 

To date, most military applications in the literature are only prototypes, 
and a majority of those are in the avionics troubleshooting, fault isolation area 
where a substantial rule base can be defined. However, just putting the mainte¬ 
nance troubleshooting procedures (decision trees), written in the form of "if-then" 
rules, into the ES knowledge base is not all that is required. That is because "too 
many unexpected causes of equipment malfunctions cannot be anticipated in a 
traditional if-then rule-based...paradigm." [Ref. 31; p. 1335] Examples of such 
malfunctions include spilled solder, damage from other equipment, or spilled 
coffee [Ref. 31: p. i335]. Some examples of the prototypes dexelopcd and pub¬ 
lished include: 

• an ES to isolate faults in "the fuel system, the flight control system, the 
auxiliary power unit, and the ax ionics systems." of the Army's AH-64A At¬ 
tack Helicopters [Ref. 32:. p. 43], 

• a prototype ES to make maintenance per.sttnncl assignments for a helicopter 
squadron's many detachments [Ref. 33]. and 

• using an ES to find the cause of electrical or hxdraulic system failures in the 
Naxy's H-46 helicopter [Ref. 34]. 

C. CURRENT EMPHASIS IN INFORMATION SYSTEMS 
I. Information as a Resource 

Most recent texts and xvritings about information systems begin by 
stressing the importance of information as a corporate resource. F('r example: 




In many organizations, the focus of information systems management has 
changed. In the past, the emphasis was primarily on managing computers 
and the technology to process information...the primary concern has shifted 
to the information in computer systems itself, and the need to manage it as a 
resource. ...information itself has become a strategic resource, requiring its 
own policies and procedures for management and control. [Ref. 16: p. 643] 

...computerized information is a resource of high value to corporations and 
other organizations. [Ref. 15: p. xix] 

Such thinking has changed the conte.xt in which organizations view information 
systems. Transaction processing systems for example are no longer an end in 
themselves. Instead, a TPS must be an integral part of an o\crall R *:'.geted at 
achieving one or more of the goals of the organization. Simply automating an 
existing system is not enough. Instead, every bit of data must in some way con¬ 
tribute to the success of the organization. This requires a ree\ aluation of the data 
being recorded. Claiming "we'\e always collected it" is no longer justification for 
including data in a system. In some cases a complete change in the transaction 
processing system, computer-based or manual, may be required. A TPS may be 
the foundation of any information system, but now an entire mission-oriented 
information system, is built on that foundation. That system is based on the 
premises that information is one of the organization's limited resources and that 
all the organization's resources, including information, must be used to achieve 
organizational goals. 

Information systems no longer merely record data and fill rooms with 
printed reports that are seldom used. Not only must they provide periodic 
printed reports, but now the reports must be pro\ ided on an ad hoc basis in an 
easy to use format. That format has e\cn taken on many forms beyond the 
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simple columnar report. Today, information can be presented in a variety of 
media from print to video and sound. Graphic displays are commonplace, with 
e\'en the most basic off-the-shelf spreadsheet package having some graphing ca¬ 
pability. Formats for presenting information to the user are limited only by 
available technology and by the user's willingness to pay. Additionally, in those 
organizations that have matured in their use of information technology, infor¬ 
mation systems are even being used to gain and keep a strategic advantage in 
their business environment. A well known example is that of American Hospital 
Corporation. They use information technology to provide better service to their 
customers and thereby increase their share of the medical supplies market. [Ref. 
3: pp. 217-234] 

2. Decision Support Systems 

Decision support systems (DSSs) started in the early 1970s. and are used 
extensi\ely today. Some say that any system that helps a decision-maker make 
a decision is a DSS. Keen and Scott-Morton refined the scope of DSS in 197S 
[Ref. 35]. Since then, much work has been accomplished, and DSS ha\c taken 
on the definition stated earlier. As the reader will recall from Figure 3 on page 
23, there are three subsystems in a DSS. The first, the Data Management Sub¬ 
system, typically has sc\eral elements, including a database, a database manage¬ 
ment system, a data directory, and some sort of query facility. This subsystem 
is intended to manage the data needs of the DSS and user. [Ref. 22: pp. 76-82] 
The Model Management Subsystem has comparable elements, a model base, a 
model base management s 3 stem, a model directory, and a model execution, inte¬ 
gration and command facility. [Ref. 22: pp. 82-83] The Model Management 
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Subsystem is intended to manage the assortment of models that a user may need 
to invoke while using the DSS. The Dialog Management Subsystem is "the soft¬ 
ware and hardware that provides the user interface for DSS." [Ref. 22; p. 86] 
The three key elements for the dialog component of a DSS are the language with 
which the user interacts with the DSS, the type of presentation the DSS provides 
the user, and the knowledge the user must possess to use the DSS effectively [Ref. 
36]. Perhaps describing characteristics of DSSs will make the differences between 
DSSs and earlier information systems, i.e., TPSs & MISs, clearer. According to 

Turban DSSs have four characteristics. They are: 

• "DSS incorporate both data and models." 

• "They are designed to assist managers in their decision processes in semi- 
structured (or unstructured) tasks." 

• "They support, rather than replace, managerial judgment." 

• "The objective of DSS is to improve the effectiveness of the decisions, not 
the efficiency with which decisions are being made." [Ref. 22: p. 8] 

Sprague and Carlson [Ref. 20] provide a framework for developing a DSS 
that they call ROMC. Representations are those things decision-makers use to 
visualize a particular problem; Operations arc those actions taken with those 
representations (which include gathering and manipulating data); Memory Aids 
are those mechanisms used to help the decision-maker retain intermediate data 
from operations with representations; and Control Mechanisms are the mechanics 
used to control the representations, operations, memory aids, and interactions 
with each user. "The ROMC approach provides a process-independent (italics 
mine) model for organizing and conducting systems analysis in DSS." [Ref. 20; 
p. 102] The critical point is that the analysis and design of a DSS should be in- 
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dependent of all processes performed in the system being analyzed. Process 
modeling is the way traditional transaction processing systems (TPSs) have been 
analyzed. The tools of traditional systems development, such as flowcharts, 
dataflow diagrams, and entity-relationship diagrams are all process-oriented, and 
not appropriate for analysis of a DSS. [Ref. 20: pp. 94-102] 

3. E.vpeit Systems 

Expert systems evolved from principles and techniques developed in the 
academic world of artificial intelligence. "Artificial Intelligence. To these words 
each of us brings his own definition." [Ref. 37] To some, AI conjures up the 
horror of computers run amok (remember HAL). To others, AI is something for 
academicians and computer "geeks," but is not real. The best perspcciixc comes 
form Shipley when he says 

Because Artificial Intelligence is an ambition more than a product, the tech¬ 
nologies and methodologies that grow out of this field are not AI. Instead, 
artificial intelligence research is leaving a trail of tools and techniques that arc 
enhancing the state of the art in computer applications development but arc 
in no real way intelligent themselves. Or, as the well-known adage in the AI 
research community goes, artificial intelligence refers to those things wc don't 
know how to do today. As soon as we figure out how to do them, they won't 
be Al. 

The point may seem simple, but it is absolutely essential to under¬ 
standing the misunderstanding, disillusionment, and initial failure of com¬ 
mercial AI. [Ref. 37] 

Expert systems arc in reality simply computer programs that manifest 
"some combination of concepts, procedures, and techniques derived from recent 
AI research." [Ref. 38: p. 5] They are the latest tool to become commercially 
available to information systems developers, and thereby, the end-users. How¬ 
ever, the increasingly sophisticated IS users are unlikely to apply ES technology 
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just because it is new. "...people buy products to solve problems...they don't buy 
technologies...." [Ref. 37] End-users will evaluate ES on the basis of whether that 
ES can solve problems. 

The principle benefit that aviation maintenance can derive from expert 
systems is consistently leveraged expertise. Consistent because an ES does not 
become fatigued, is not subject to high stress, and can't be distracted. Therefore, 
the mistakes that even experts could make when tired, stressed, or distracted 
would not be made by an ES, or by someone consulting an ES. This is not to say 
an ES is infallible. In fact, an ES is only as good as the expertise in its knowledge 
base, and that expertise is a function of the expertise of the original expert and 
the accuracy with which the knowledge engineer translated that expert's know¬ 
ledge into an ES. Nor can an ES "know" everything, any more than a human 
expert. Howe\er, unlike the human expert, an ES has no ego to get in the way 
of saying "1 don't know." Instead, depending on how the inference engine is 
"trained" to respond, an ES will either ask the user for more data, or pro\idc the 
user a conditional response. 

The leverage deri\es from the fact that once in the ES, the expert's ex¬ 
pertise can be used by anyone, anwhere. The expert docs not c\cn need to bo 
by the phone! Additionally, experts, rather than spending their time soKing 
routine problems, are free to spend their time on those decisions for which the 
expertise has not yet been captured, or for which a computer-based system is in¬ 
appropriate. 

"Expert systems free workers from more mundane tasks so that they can 
spend their time on more difficult problems or more crcaii\c cndea\ors. Dc- 
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cisions are made consistently from worker to worker, and the know-how of 
top employees and specialists can be distributed throughout the corporation. 

Expert systems also translate directly into cost savings. An IBM di¬ 
agnostic system saved SI2 million per year...by avoiding misdiagnoses and the 
accidental disposal of good parts. DuPont, a true believer in expert systems 
spends an average S25,000 to build a system that promises an initial payback 
of 5100,000." [Ref. 37] 

So, by providing the expert's knowledge to a large number of organizations, in the 
form of an ES, we, aviation maintenance managers, in essence multiply the 
number of experts we have, AND use them more effectively. 

Through the 1960s and 1970s, computers evolved in two directions. In 
the scientific and academic communities, the focus was on number crunching and 
artificial intelligence. In the business community, the focus was on automated 
accounting, financial reporting, and rudimentary information management. To¬ 
day, as the integration of TPS. MIS, DSS and ES occurs in the "Information 
Age," we are beginning to rc-unite those once separate paths of information sys¬ 
tems de\'elopment [Ref. 25: pp. 2-3]. 

4. End-User Development 

"One of the most exciting trends on the people front of information sys¬ 
tems invohes knowledge workers' participation in information systems dc\clop- 
ment." [Ref. 13: p. 84] The proliferation of micro computers, coupled with an 
increase in computer literacy throughout the work force has brought about a 
phenomena called "end-user computing." End-user computing is not the same 
as end-user involvement. End-user involvement is exactly that, in\ol\cmcnt. 
That is, the end-user pro\idcs the developers with the requirements, feedback 
about progress, and appro\al of the final system. End-user in\ol\ement has be- 
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come a requirement of all systems development projects.« On the other hand, 
end-user computing, or end-user development^, is the end-user doing the de\cl- 
opment of the entire system themselves, with or without assistance from IS pro¬ 
fessionals. 


"...end-user development...BccaL\is,c the end-user totally controls the design ef¬ 
fort, there is little need to go through a traditional systems design life cycle. 
Moreover, today, end-users are much more sophisticated about information 
systems than they were in the 1960s. Therefore, they can play a larger role 
in systems design. 

End-user development does not necessarily mean total end-user con¬ 
trol of projects. There are ways in which end-user development can be as¬ 
sisted by professional systems personnel...." [Ref. 16: p. 423] 


Whether it be de\elopment or involvement in de\elopmcnt, the end-user is play¬ 
ing a greater role in building information systems to satisfy their own needs. 

Some claim that end-user computing de\clopment will relieve some of the 
huge backlog!') of systems under development. Others claim end-user computing 
will only make the backlog worse as IS professionals have to repair and maintain 
user "developed" systems. [Ref. 25; pp. 233-234] "In one-fifth of data processing 
shops. 85 percent of personnel hours arc allocated to maintenance, leav ing little 
time for new systems development." [Ref. 16: p. 420] 


8 With the advent of Total Quality .Management end-user involvement has received increased 
emphasis. The end-user is the "customer" that the information system, and consequently the s_\s- 
tem's developers, must satisfy. 

9 Some even differentiate between end-user computing and end-user development, claiming 
that end-user computing is merely using the computer, and end-user deselopmg is actually de\el- 
oping computer-based information systems. The distinction is moot in this context 

10 ITie explicit backlog is that set of applications that has been formalh staled and given to 
IS professionals to develop. The impbeit, sometimes called 'hidden ', backlog is that set ot appli¬ 
cations that users would like, but haven't bothered to specify because the explicit 'nacklog is so 
huge. 
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End-user computing is really just another part of the IS puzzle that will 
need to be nurtured, managed, encouraged and controlled. "It has become clear 
that techniques are needed for guiding end-user computing to prevent a Tower 
of Babel from springing up as a result of randomly designed data and redundant 
procedures." [Ref. 15: pp. 40-41] Many benefits can be gained from a carefully 
considered and nurtured end-user development environment. Conversely, the 
risks of not managing end-user development are also great. 

(I) Benefits. "The primary benefits of end-user development are 
improved requirements determination, reduced application backlog, and in¬ 
creased end-user participation in and control of the systems de\elopment proc¬ 
ess." [Ref 16; p. 489] Better requirements determination would occur because the 
users are the ones who know what they really want. If the end-users develop the 
system themselves, they can make assumptions and compromises appropriate to 
the importance of the application, without having to explain those assumptions 
to someone unfamiliar with their real requirements. In effect, end-users practice 
a dc\elopment methodology called "iterative prototyping." (More about that in 
“c. Prototyping” on page 48.) 

The application backlog, both explicit and implicit, of systems 
awaiting development will decrease as more users develop their own systems. 
Approxiniaieiy 60 percent of iS professionals' time spent maintaining existing 
systems is spent on enhancements [Ref 18: p. 711]. If users were developing their 
own systems to satisfy the requirement for the enhancement. IS professionals 
would be able to spend more time building new systems. The backlog is reduced 
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in two ways, end-user development, and re-directing IS professional's time from 
maintenance to new systems development. 

Finally, the increased end-user participation and control occurs 
as the end-users become increasingly literate about systems development. The 
control is a natural by-product of increased familiarity and a "Gee, 1 can do that" 
attitude. 

(2) Risks. End-users may not have the entire picture of the or¬ 
ganization's functions. Consequently systems they develop may be based on in¬ 
correct assumptions about the business and its direction. [Ref. 18: p. 722]. The 
simplest example would be of a user developing a system to manage an aspect of 
the organization that is soon to be dixested. closed or shut down. A product that 
is soon to be phased out is one such situation. In this case, the user's dc\elopmcnt 
time is lost as well as the opportunity for that user to be working on something 
else of real \’aluc to the organization. 

Another risk is that end-users may use software inappropriate 
to their needs. [Ref. 18: p. 722] In such cases, the end-users' dc\elopment lime 
may be far greater than needed. They may find, after much effort has been ex¬ 
pended, that they can't accomplish what they want with the software thcy'\e 
chosen. Now they must start all over with software better suited to their partic¬ 
ular application. For example, someone who has experience with a particular 
spreadsheet package may try to develop a database application using that 
spreadsheet package. Although most spreadsheet packages ha\e some database 
management capabilities, their primary focus is on spreadsheet applications, and 
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any database capabilities they have are limited.n Database management pack¬ 
ages are particularly well suited for easy development of database applications. 
Much time can be lost finding work-around solutions in the spreadsheet software 
to problems that are handled as a matter of routine by database management 
software. 

One of the major risks associated with end-user de\elopmcnt is 
that standards of development, learned through the school of hard knocks by IS 
professionals, will not be followed. [Ref. 18: p. 722] Those standards could be 
incorrectly or inadequately applied by the end-users. An end-user de\eloped in¬ 
formation system that contains an incomplete data dictionary directory system 
(DD DS)i- is an in\’itation to future disaster. A DD DS that does not contain 
all data elements or locations of these elements, when used to locate where in the 
IS a particular data element is used, could render any changes made based on the 
DD DS into time bombs. Subsequent users would faithfully use the results from 
the system ne\'er realizing that its accuracy and effectiveness had been compro¬ 
mised by the simple but incomplete change(s) made previously. 

Another area of risk is that of the stored data itself. When there 
arc many user developed svstems, data is stored in all of them. W'hich of these 


11 The old conventional wisdom about tning to satisfy two or more objectives inevitabls 
leading to one or the other or both of the objectives being compromised is particularly applicable 
to software packages, 

12 A data dictionars is a dictionary of aU the items of riata used in a particular information 
system. It shows what the format o. the data must be, and what the data element represents. 1 or 
example, SSN is 9 numeric characters in the format imn-nn-nnnn, representing an individual's so¬ 
cial security number. ITie director) portion lists each and every use of that data element w ithin a 
system thereby helping to prevent changes to the system from being incomplete, for example, 
changing an interest rate in one part of a system and not in another, ,\nother function of the di¬ 
rectory is to identify who, which person or office, controls the format and use of that data element. 
I'his to prevent changes that may impact other users of the system. 
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disbursed data bases has the current, correct information? [Ref. IS: p. 722] Who 
decides which system is the one to solve a particular business problem? How does 
a business integrate all the different user databases? If there is a central data¬ 
base, who is allowed access, either just to look (read only) the data, or to change 
(read/write) the data? These questions become more important as the size of or¬ 
ganization increases and there is a corresponding increase in end-user develop¬ 
ment. 

Organizations must de\elop new policies and procedures concerning system 
development standards, training, data administration, and controls to man¬ 
age end-user computing effectively. [Ref. 16: p. 490] 

a. End-user Computer Literacy 

The fact that computers have been around for years, and ha\e infil¬ 
trated our schools means that as new people enter the work force they do so with 
less fear of computers and with a knowledge of what computers can do for them. 
This increased literacy is bound to lead to an increased demand for computers 
and computer-based applications that help knowledge workers do their jobs more 
effectively. For example, the Naval Academy now requires e\ery student to ha\e 
his'her own personal computer. This will ha\e increasingly significant impli¬ 
cations for what those students expect of the systems they use in the fleet. Fur¬ 
thermore, those computer literate students will form a talent pool in the Navy 
with the training and motivation to support information systems projects such as 
OASIS which is really a co-ordinated "build it ourselves" project. 
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b. Increasing Power of Micro Computers 

It is no secret that the capability of a mainframe computer of 15 years 
ago is now contained in the micro computers of today. The speed and memory 
capacity of computer hardware has increased dramatically, sometimes even dou¬ 
bling in a few short years. Software, while not making such dramatic leaps as 
hardware has also made great strides. The ease with which users can learn and 
effectively use most software packages means that an -nd-user must no longer 
hold a degree in computer science. These two trends are making large mainframe 
systems virtually obsolete when it comes to satisfying small end-user require¬ 
ments. Using to maximum advantage the increased speed, increased memory and 
more powerful software available in modern micro computers MUST be one of 
the principle criteria for any new information systems development. 

c. The Proliferation of Micro Computers 

Starling with the purchase of the Zenith model 120, micro computers 
have been the largest growing "population" in the Navy. One can't go to any 
command without finding some form of micro computer. Many of these tools 
have been pushed on small commands by higher authority-"Hcre you are, try to 
use it" approach. People in aviation maintenance tend to use everything at their 
disposal to accomplish their jobs. Their resourcefulness has its own legendary 
subculture. There are even tales of entire aircraft hidden away as spares. .Al¬ 
though the publicity of recent years has changed things somewhat, manipulating 
the system to get whatever is needed to accomplish a mission is still practiced. 
Accordingly, when they were provided another tool, it was onlv a matter of time 
before they used it. The author is personally familiar with applications developed 
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by people in OMAs that track financial data, personnel assignments, training 
records, tool inventories, technical publications, flight hour accounting, as uell 
as such simple things as pilot qualifications. Additionally, information systems 
ha\e been and arc being developed by students here at the Naval Postgraduate 
School, not to mention electronic bulletin boards that have sprung up for the ex¬ 
change of specific applications that have been dc\ cloped. 

d. Development Backlog 

As has been previously mentioned, a backlog of systems awaits de- 
\elopment. The size of this backlog is typically measured in years. The most 
common range is three to seven years. What that means is that if one were to 
gi\e a de\elopment project to a developer today, he would not e\en start for at 
least three years. To someone with a problem, such a dcla\ is unacceptable. He 
will find another way to sol\c the problem. "Users are accustomed to achieving 
goals in their own fields with a consistency that is unheard of in the software 
world." [Ref. 4: p. 4] Consequently, many frustrated end-users resorted to build¬ 
ing their own systems, becoming computer literate along the way. (Incidentally, 
the end-users in the fleet arc used to meeting performance goals, e.g.. readiness. 
MC. FMC. training Ic' cls, pilot training rate, far abo\e anything that an> infor¬ 
mation system provided or promised them has actually met.) 

e. Concerns of IS Professionals 

End-user computing can be perceived as both a threat tt) and a relief 
to IS professionals. On the one hand, their bad reputation for being late, over 
budget and incomplete with IS projects can only be helped if they ha\e less 
backlog. On the other hand, if the end-users become proficient at de\cIoping 
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applications, IS professionals may see themselves being replaced. The reality of 
the situation is that the end-user doesn't want the IS professional's job; he just 
wants the tools to do his own job better. There will always be a need for a "better 
mouse trap", and e\en for the tools with which to build the better trap. 

Since information has achieved status as a corporate resource, it must 
be protected as a resource. The security of the information is as important as the 
security of any other corporate asset. Proliferating micro computers make main¬ 
taining data/information security particularly difficult. A computer on e\ery 
desktop proN’ides the means of obtaining corporate secrets to any one who knows 
how to use the computer. A comprehensixe security plan is now necessary to 
protect both the physical and electronic assets of the organization. 

A closely related issue is that of data integrity. Who is allowed to 
change the data is particularly important, along with the timing and frequency 
of those changes. If two or more different copies of information somehow man¬ 
age to exist at the same time, which one is correct or most current can be a par¬ 
ticularly difficult problem to sohe. It is only exacerbated with each additional 
micro computer. A closely related issue of ownership must also be addressed. 
The user, i.e., person, office, or command, that "owns" a particular bit of data or 

information is entirely responsible for that information. He 

• establishes the requirement for that information. 

• determines the format of that information, 

• maintains the description and definition of that information. 

• authorizes access to and use of the information. 

• and authorizes changes to an\ of the aboxc. 
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The concept of information ownership is important when designing an informa¬ 
tion system. Designers must work closely with information owners to ensure that 
the owners' requirements are met, while at the same time impressing on the 
owners the potential impact on the IS of any changes they, the owners, might 
make. Changing the format of a single data element such as a date could require 
changing storage formats, forms, and users' habits; moreover, the change will 
have ramifications proliferating throughout the organization. Information own¬ 
ership carries the responsibility of deliberate change, if any, and long term sta¬ 
bility. 

Another very important issue is data administration. "Data adminis¬ 
tration,..\s> concerned with the planning, admiristrati\e, and control functions for 
managing information...It is responsible for policies and procedures through 
which data can be managed as a companywidc resource." [Ref. 16: p. 646] This 
is closely related to the data dictionary directory system discussed earlier. ''Data 
administration is more organizationally or business oriented....'' [Ref. 16: p. 645] 
Additionally, data and information, recognized as a resource, are being treated 
as a resource of the entire organization, not just one part of that organization. 

The most fundamental principle of data administration is that all data are the 
property of the organization as a whole. They cannot belong e.\clusi\cly to 
any one business area or organizational unit. All data are to be made avail¬ 
able to any group that requires them to fulfill its mission. [Ref 16: p. 645] 

The last concern of IS professionals to be discussed is that of end-user 
development running rampant with no guidance, no controls and few if any ap¬ 
plied standards. As discussed in “(2) Risks” on page 40. these standards can 
ha\'c a significant impact on the system's performance and accuracy. IS profes- 
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sionals fear that end-users will buy anything and everything. Whether because 
it is the latest computer fad or because the end-users don't know any better does 
not really matter. The analogy of child in a candy store is apropos. The solution, 
as with the child, is to allow the growth of end-user computing within limits as 
long as the organization's missions and problems are being addressed by the 
growth. This concern may in fact not be long-lived. As end-users become more 
IS literate, they wilt be less likely to buy anything more than a solution to their 
particular problem [Ref. 37]. 

5. Techniques and Methods 

Three techniques and methods arc rclc\ ant to the development of O.^SIS. 
They are Structured Analysis and Design techniques. Information Engineering, 
and Prototyping. 

a. Structured Techniques 

Since TPSs were the first step in the evolution of computer-based in¬ 
formation systems, a large body of knowledge exists today about how to design, 
build and implement such systems. A variety of methods and techniques to an¬ 
alyze and design systems, as well as a plethora of designers, and e\cn entire 
businesses, arc now available to support TPS dc\elopmcnt. [Refs. 2. 15, 39. 40 , 
and 41] Most emphasize the information requirements of an organization, and 
take a very formal, rigorous approach to modeling the existing systems. Sc\eral 
well known adxocates are DeMarco [Ref. 4], Yourdon [Ref. 39], and Page-.loncs 
[Ref. 40]. 
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b. Information Engineering 

The second technique, in fact almost a philosophy, is Information 
Engineering (IE). The term "information engineering" implies the rigor and dis¬ 
cipline associated with the more traditional engineering professions (such as civil, 
mechanical, chemical and electrical engineering). In fact, over the past decade, 
the development of information systems has progressed from the "art of pro¬ 
gramming" to a set of formal, rigorous disciplined techniques. Now, "the term 
information engineering refers to a set of interrelated disciplines which arc needed 
to build a computerized enterprise based on data iy5rem5...The basic premise of 
information engineering is that data lie at the center of modern data processing." 
[Ref. 42: p. 92] IE had its origins with IBM's Business Systems Planning program 
in 1970 [Ref. 43]. Among the well known ad\ocates of IE today are James 
Marlin, Te.xas Instruments, and Clive Finkclstein. They all recommend concen¬ 
trating on the organization's missions and goals instead of the existing systems, 
evaluating the data required to achieve those goals, and building information 
systems to provide and manage that data. In some cases, existing systems can 
be integrated into the otherwise all new IS. (This is what I recommend for 
NALCOMIS OMA. We have wasted enough time and money on it already. 
Let's not throw more at it. Instead, treat it as a 'sunk' cost and get on with what 
OMAs really need. Use what can be used from it, but most importantly. 
LEARN from the debacle so we don't repeat it!) 

c. Prototyping 

A prototype is a one-of-a-kind t)pe of item built to determine what 
is really needed. Prototyping then is the process of building a protot> pe. generalh 
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with the idea, either implicit or explicit, of throwing it away once the real re¬ 
quirements have been determined. Prototyping provides a way to "buy" infor¬ 
mation from the end-users about what they really want, "...plan to throw one 
away; you will, anyhow." [Ref. 44: p. 116] There are now two approaches to 
prototyping, throwaway and evolutionary [Ref. 22: p. 150]. The evolutionary dif¬ 
fers from the traditional throwaway in that it is intended to evolve, through as 
many iterations as necessary, into a deliverable system. There are several key 
benefits of prototyping—the iterations occur quickly; the users pro\ ide feedback 
on each iteration, and thereby stay involved in the development; and the cost is 
typically lower than traditional life cycle development [Ref. 22: p. 152], A ben¬ 
efit of particular \alue to de\eloping OASIS is a situation with many geograph¬ 
ically disbursed users. In that situation, a prototype allows you to "get the idea 
out" to many of them, keeping many of them in\'olved. and a\ oiding some of the 
"just another program form headquarters" acceptance problems. 

D. INFORMATION SYSTEMS IN AVIATION MAINTENANCE 
1. Background 

Information systems intended to make maintaining aircraft more effecti\e 
and efficient have been under development for years. The Maintenance Data 
Collection System (MDCS) was developed to "insure that basic data generated 
by maintenance personnel arc recorded once, and only once, and that the system 
(not the maintenance activity) thereafter provides information to all who ha\e a 
need for it in such forms as may be useful." [Ref. 8: p. 1-8] The MDCS became 
the Maintenance Data System (MDS) [Ref. 45]. Within this system coded data 
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describing every maintenance action is recorded on a formic. These forms arc 
then collected, checked for accuracy and conformance to NAMP standards by 
an analyst at the OMA, and taken to a Data Services Facility (DSF) to ha\c the 
data on them keypunched, i.e., entered into a computer system via keyboard. 

The volume of these transactions is very large, and processing large vol¬ 
umes of data is "the aim of record-keeping systems." [Ref. 18: p. 446] Consider 
a hypothetical situation: there are 300 OMAs, ten aircraft per OMA, and each 
aircraft has, on average, five transactions associated with it daily. That would 
amount to 15,000 per day, and would not account for fluctuation. In a year there 
would be 5,375,000 transactions to be collected, stored, sorted and summarized. 
This hypothetical situation is less than what really occurs. There are really over 
400 OMAs, and an aircraft with only five documented transactions per day is a 
very rare aircraft indeed. The MDS, of necessity, became a management re¬ 
porting system, which at pre-specified intervals produces pre-defined reports 
based on the data collected and stored by its supporting TPS [Ref. 13: pp. 71-72). 
It produces daily, weekly and monthly listings of all transactions, and summaries 
of those transactions for the OMAs & IMAs. When the stored data has been 
\erified and corrected, summary reports arc sent upline to higher authorities. 

NAVAIR realized that the raw data being collected in support of aircraft 
maintenance was outstripping the ability of managers to assimilate it, and the 
sheer volume of data was making the reports and summaries less and less timely. 

13 Even though it's called the MAIN rEN.ANCI! Data System, the MDS collects k)gistics and 
operations data as well. Several forms are used in the .MDS, including the Maintenance .\ction 
Eorm (MAE), the Support Action Eorm (S.AE). and the Naval 1 light Information Record 
(NAVM.IR). 
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and therefore of less value for making time-critical decisions. The batch proc- 
essingi4 TPS just was not meeting the needs of all its intended users. In 1974, a 
Management Information System was conceived to allow data to be collected 
only once, and make information, instead of simply data, available to those who 
needed it, both the operating units and higher authorities. The Naval Aviation 
Logistics Command Management Information System (NALCOMIS), was in¬ 
tended as "a modern computer system to provide timely and accurate aircraft 
maintenance, operations, and logistics data." [Ref. 46: p. 1] NALCOMIS was 
aimed at supporting "day-to-day maintenance and supply activities," i.e., OMAs. 
IMAs, and Supply Support Centers (SSCs) in addition to satisfying upline re¬ 
porting requirements of Na\y and Department of Defense Program managers 
[Ref. 46: pp. 3-4]. Given the enormity of the tasks it was to perform. 
N.ALCOMIS was broken into three phases [Ref. 11: pp. 3-4]. Phase 1 was an 
interim s\stem, implemented at only a few activities, called NALCOMIS Rc- 
pairablcs Management Module (NRMM) [Ref. 11: p. 3]. Phase II addresses the 
information needs of IMAs and SSCs, and pro\ides external interfaces to other 
related information systems such as AV-3M (A\ iation Maintenance and Material 
Management), SUADPS (Shipboard Uniform Automated Data Processing Sys¬ 
tem), UADPS (Uniform Automated Data Processing System), and of course. 
NALCOMIS OMA [Ref. 47: pp. 36-37]. Phase III of NALCOMIS, also called 
NALCOMIS,OMA, was intended to automate the OMAs [Ref. 48: p. 3-1]. 

14 Batch processing occurs when "all data and transactions are coded and collected inti) groups 
(batches) before processing." |Ref. IS: p. 3()6| 
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2. Current Situation 


Many information systems are intended to support the three levels of 
aviation maintenance. The Naval Air Systems Command (NAVAIR) is the 
principle sponsor of such systems.15 The majority of information systems devel¬ 
oped or planned for aviation maintenance have been large systems, i.e.. requiring 
a mainframe or at least a mini computer. Until micro computers became capable 
of performing some of the required functions, building large systems was \ irtually 
the only way aviation maintenance could hope to reap benefits of computerized 
information systems. 

Unfortunately, "...large systems development projects are often 30 percent 
over budget and require 50 percent more time than the early estimates developed 
in the project plan of a traditional systems life cycle. Unfortunately, large-scale 
projects ha\ e de\ eloped a reputation for being much more costly, and much later, 
than expected." [Ref. 16: p. 418] 

NAVAlR's Component Information Management Plan (CIMP) [Ref. 
49] lists all information systems currently being planned or developed to support 
NAVAIR missions. The four "functional areas" for which information s\stems 

are being developed are: 

• Logistics, 

• Systems & Engineering, 

• Contracts, Administration and Business, and 

• Support Systems. 

15 rhe Naval Supply Systems Command (NAVSt P) has a vested interest in such ssstems 
since NAV'SLP is tasked with material support of aviation activities. 
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As it turns out, "the majority of NAVAlR's current major ISs reside in the avi¬ 
ation logistics functional area." [Ref. 49: p. 1-11] This is not surprising, since 
NAVAIR's primary mission "is to provide for the full range of material support 
needs of the operating forces of the Navy for aeronautical weapons systems." 
[Ref. 49: p. 1-6] 

Within the Logistics functional area, there are 26 different information 
systems described in the CIMP. They include local area networks (LANs) for 
specific commands, systems dedicated to supporting one level of maintenance, 
systems designed to address one aspect of aviation logistics support at all three 
le\els of maintenance, and systems with requirements to provide extcnsi\e sup¬ 
port throughout all of NAVAIR and the operating forces. Of those systems, 
three can ha\e a direct impact on an OMA's ability to perform its missions. They 
are: 

• A\iation Training Support System—Phase 11 (ATSS 11), 

• Naval A\iation Logistics Command Information Systems (NALCOMIS). 
and 

• Support Equipment Resources Management Information Svstem 
(SERMIS). 

ATSS 11 "provides Fleet Readiness Squadrons (FRS) with an automated man¬ 
agement support system to improve the efficiency of all aircrew and maintenance 
training." [Ref. 49: p. LOG-10] From the OMA point of view, ATSS 11 provides 
them with a record-keeping capability for the training records of their personnel. 
The primary intent however is to help manage the training evolution itself, and 
only peripherally to support the OMAs. SERMIS is a system intended to help 
Support Equipment Controlling Activities (SECAs) perform their mission of al- 
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locating, inventorying and reworking support equipment used by all aviation ac¬ 
tivities in the Navy. [Ref. 49: p. LOG-101] Again, accomplishing an OMA's 
missions is not the real purpose. NALCOMIS however, was intended from its 
inception to satisfy the information needs of organizational and intermediate 
maintenance activities throughout the Navy. 

Of those described, only NALCOMIS was intended to provide aviation 

logistics, material management and administrative support to OMAs. 

There are four primary objectives of NALCOMIS. each of which has 
a major impact on the mission capability and overall personnel effectiveness 
at the Organizational Maintenance Activity (OMA), Intermediate Mainte¬ 
nance Activity (IMA), and Supply Support Center (SSC) levels in support 
of the Naval Aviation Maintenance Program (NAMP). 

The four objectives are: 

(1) Improved aircraft mission capability. 

(2) Improved aircraft maintenance and supply support. 

(3) Improved upline reporting to satisfy Navy and Department 
of Defense (DOD) program requirements. 

(4) Modernized management support. [Ref. 49 : p. LOG-81] 

NALCOMIS is a very large system. The estimated total dollar require¬ 
ment for the period FY88--FY94 is 5204.333,000. When one recalls the reasons 
NALCOMIS came into being, and the number of transactions it was intended to 
handle, large was inevitable. 

Large systems such as NALCOMIS, while seeming to provide an overall 
integrated system that realizes economics of scale, have by their v ery size not been 
able to take advantage of the tremendous increases in computer speed and mem¬ 
ory, or of the decrease in physical size that have occurred. For example, when 
NALCOMIS was first envisioned, who could have realistically thought that 13 
years later, all of the requirements could be satisfied by hardware and software 
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silling on someone's desk. Such is the case, yel because of ihe magniiude of ihe 
projecl in 1976, and ihe technology then available, a development time of 15 
years was unavoidable. If NALCOMIS were the only example of large systems 
development, then the fact that it has taken so long to field could be attributed 
to poor project management. Such is not the case. In fact, the entire information 
systems industry has been plagued by projects that arc late, are over budget and 
don't perform as intended. "A construction job is considered a debacle if it 
overruns six percent." [Ref. 4: p. 4] It is possible that such projects were too 
ambitious from the outset. However, this author believes that the ambitious goals 
were not the problem, but that technology outstripped our ability to take advan¬ 
tage of it. 

3. Previous Recommendations and Requirements 

McCaffrey [Ref. 6], explored the use of an expert system for discrepancy 
scheduling with NALCOMIS. He concluded that an ES was both 'easible and 
desirable. Howe\er, one of his premises was that the system would run on the 
same hardware as NALCOMIS OMA. At the time, (1985), NALCOMIS OMA 
was scheduled to be implemented on a Honeywell mini-computer. McCaffrey's 
ES was intended to be run only two to three times a day, and because of the 
processing demands of the ES, would lockout other NALCOMIS processes while 
running. 

Allen & MeSwain, in their thesis [Ref. 7] carry McCaffrey's work further 
and propose something more than just an ES, specifically a DSS ES for the MC 
arena. They offer a set of design, c\aluation and implementation criteria. They 
recommend a prototype that addresses the problem of assigning aircraft to par- 
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ticular missions on the flight schedule based on the needs of the mission, and the 
mission capability of the aircraft. 

E. SUMMARY 

In summary, information systems have evolved from manual transaction 
processing systems through computerized transaction processing systems, man¬ 
agement information systems, decision support systems and expert systems to the 
integrated concept of today where an information system may include any com¬ 
bination of them. Information is now considered a resource. Information sys¬ 
tems are the tools with which to manage that resource while focusing on 
accomplishing an activities goals. 

Advances in technology have made the laptop of today the equi\ alent of the 
mainframe of 15 years ago. Software development has exohed to the degree that 
many consider it a field of engineering. Computer and information technology 
has mo\ed from the back room to front office. Developing information systems 
has become less "art" and more "science." That science is being applied in many 
ways to benefit and improve the uses and development of information systems. 

End-users are becoming increasingly willing and able to dcxclop their own 
information systems. The tools for them to do so are readily available. So readily 
available that managing end-user computing has become a concern of informa¬ 
tion systems professionals. 

Decision support systems and expert systems have become significant parts 
of many organizations information management. In fact, use of ESs is growing 
so rapidly that an organization that ignores them risks being at a compeiiii\e 
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disadvantage. The consistent leveraging of expertise is allowing organizations 
that do use ESs to produce better products and provide better services. 

In spite of all the advances in computer and information technology, OMAs 
still do not have an information system. In spite of all the effort and money spent 
to get them one, they still lack the modern tool to effectively and efficiently 
manage their information as resource. Not only must managers at OMAs man¬ 
age huge piles of paper searching for necessary but sometimes obscure informa¬ 
tion, but in this era of diminishing funding, they may have to manage with fewer 
experts as well. OASIS will fill this growing gap. 
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IV. PROPOSED INFORMATION SYSTEM, OASIS 


This chapter comprises the actual proposal for the Organizational Acti\ity 
Strategic Information System (OASIS). First the strategic and functional re¬ 
quirements will be discussed, then the actual modules that should be imple¬ 
mented, then a preliminary implementation plan, and finally a discussion of 
potential problems and benefits. 

A. STRATEGIC AND FUNCTIONAL GOALS 

The adage "If you aim at nothing, you'll hit it e\ery time?" certain!}' applies 
to organizations. An organization needs to have some idea of what it is trying to 
do. and how it plans to do it. This "direction" of the organization should be ex¬ 
plicit. In large organizations, such as the Navy, determining this direction is 
normally a formal planning process. The planning process should pro\ide an 
organization with a statement of its goals in a form that can be used throughout 
the organization, a statement of its current situation relatixe to those goals, and 
a detailed plan of how it is going to achie\ e those goals. There are normally three 

steps to this process and they are: 

• Goal Formulation, 

• Current Situation Analysis, and 

• Plan Formulation. 

Goal formulation encompa.sses three basic activities; "...understanding the 
organization's purpose, defining its mission, and establishing the objectixes that 
translate the mission into concrete terms." [Ref. 17: p. 123] Current situation 
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analysis is an evaluation of where the organization is now in relation to its goals, 
any identifiable threat(s) to achieving its goals, and any identifiable opportunities 
the organization should exploit. [Ref. 17; pp. 124-125] Plan formulation is where 
alternative ways of achieving the organization's goals are e\aluated and the one 
the organization will follow is identified and promulgated throughout the organ¬ 
ization. [Ref. 17; pp. 127-128] 

An OMA's goals arc derived from the objective of the NAMP, which "is to 
achicN'c and continually upgrade the readiness and safety standards established 

by CNO." [Ref 9: p. 1] Those goals are to; 

• Increase efficient and economical management of human, monetary, and 
material resources, 

• Ensure the maintenance, manufacture, and calibration of aeronautical 
equipment and material occurs at the le\cl of maintenance that will ensure 
optimum use of resources, 

• Ensure the protection of weapons systems components from corrosi\e ele¬ 
ments through an active corrosion prevention program. 

• Ensure the optimum application of a systematic planned maintenance pro¬ 
gram, and 

• Collect, analyze, and use pertinent data to effectixel}’ improxo material 
readiness and safety. [Ref. 9; p. 1] 

Of these, the middle three arc simply more specific sub-goals of the first. The 
last is the traditional goal of an IS, collecting and analyzing data. Placing it last 
shoukl scr\e to emphasize that an information system is the tool for managing the 
informatit)n needed to achieve all the other goals, and nothing more. 

The most important of the NAMP goals is the first. It identifies the three 
main categories of resources that must be managed. ' Human' incliKics aircrew, 
maintenance anti support personnel. .AND their training; 'nionctarv at tlic 
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OMA is primarily concerned with operating target (OPTARi^) management; and 
"material" includes aircraft, ordnance, parts, supplies, publications and informa¬ 
tion. This div ision will form the basis for the proposed modules of OASIS. 

A distinction needs to be made between the goals of an OMA and the goals 
of OASIS. An OMA's goal is to achieve and maintain CNO standards of read¬ 
iness and safety. OASIS's goal is to help OMA maintenance professionals man¬ 
age all their resources effectively so that the OMA's goal can be achieved. 
However, OASIS is an information system and as such OASIS must try to 
achieve the applicable goals published for all Navy information systems. Those 
goals are promulgated in SECNAVINST 5230.10, the IRSTR.ATPL.AN [Ref. 
50]. Although they are not the underlying reasons for developing OASIS, the 
IRSTRATPLAN goals for information systems must be considered. The seven 

goals of the DON IRSTRATPL.^N are: 

• "To enhance the productiv ity of DON components." 

• "Make information technology a force multiplier." 

• "Improve responsiveness to mission requirements." 

• "Streamline the computer resource and information svstems acquisition 
process." 

• "Provide quality equipment, software and serv ices." 

• "Protect DON resources." 

• "Ma.ximize the exploitation of technology." [Ref. 50: end. (1), pp. 13-IS] 

Hav ing established the goals of OMAs and OASIS, the next step is to ev alu¬ 
ate the current situation, specifically with regard to information systems for 

16 An Ol’ I'AR is an operating target that an activitv is gi\cn periodicalls h\ its t\pe or tleet 
comm:inder. It is an administrative limit on the amount of funds the aeti\ its can obligate from tlie 
operations and maintenance. Nav\ (()<XM.N) appropnation. ()M.\ s t\picall> recei\e an Ol’ I .\R 
for fliglit operations, and an OI’ l AR for aviation licet maintenance |Ref ID: p 6-l.t2| 









OMAs. Even though a more thorough evaluation might be thought necessary 
by some, the result will be the same. That is, OMAs do not have an information 
system with which to effectively manage information about all their resources. 
They may have parts of one, but not all OMAs have the same parts, and not all 
parts are the same. In other words, OMA "A" may have dc\’cloped a spreadsheet 
to help track and manage its fuel expenditures, while OMA "B" may ha\e de\el- 
oped a database to help track and manage the qualifications of its aircrew. 
Further evaluation should be done to establish exactly what has been de\eIoped, 
and the applicability of those applications to all OMAs. Such a study should also 
assess the hardware currently held by OMAs, so that budgeting to acquire any 
additional hardware could begin immediately. 

Since so much effort has already been expended de\eloping functional re¬ 
quirements for NALCOMIS, they should be re\iewcd and e\aluated with the 
end-users for applicability to OASIS. A brief list of the N.-\LCOMIS functions 

is extracted from Reference 46, page 4, and repeated here: 

• 'The proper identification of maintenance problems, along with the right 
maintenance skill and material to do the repairs...." 

• "Verify repair completion and determine material readiness." 

• Make the current workload readily \isiblc to maintorance managers. 

• Establish a maintenance schedule based on the "priorities of a\ailable re¬ 
sources including skills, worker hours, material and support f'-yaipment." 

• Assist in the assignment of "properly skilled persons to p'Jbrm maintenance 
actions." 

• Provide supply and OMA maintenance managers with "timeh notiricatii>n" 
of material requisitioning and deli\ery. 

• Provide OMA maintenance managers with the "a\ailability and operability 
of aircraft." 

• Pro\idc summarized oxerall status "for management \isibilit> in a timely 
fashion.' 
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• Provide for tracking inventories of "repairable components, support equip¬ 
ment, component parts, requisitions, personnel, and maintenance capabili¬ 
ties." 

The next section provides a brief review of the NALCOMIS subsystems. The 
following sections will describe the modules of OASIS, and address the last step 
in the planning process, formulating a plan composed of the objectives that add 
substance to the goals, i.e., the specific functions that OASIS will perform. 

B. NALCOMIS 

To support the functions described in the previous section, 
NALCOMIS OMA was di\ided into ten subsystems. The brief descriptions in 
the following sections are extracted from Reference 46, pages 9-10. 

1. Data Base Maintenance 

This subsystem was to be the data base housekeeper. It "establishes and 
maintains the non\'olatile data within NALCOMIS and performs local data base 
support functions for all subsystems." [Ref. 46: p. 9] Such functions as purging 
no longer needed data and transferring data to historical archi\es were included. 

2. Flight Activity 

This subsystem was to collect flight hour data for use by other subsys¬ 
tems. The data collected is that which is now collected on the Na\al Aircraft 
Flight Record (NAVTLIR) form. This data was to be used to track aeronautical 
equipment usage for planning scheduled maintenance. 

3. Maintenance Activity 

This subsystem was intended to "perform fully automated processing of 
the Visual Information Display System Maintenance Action Form 
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(VIDS/MAF)." [Ref. 46: p. 9] This subsystem was also intended to include the 
automation of the Support Action Form (SAF), and provide various reports to 
management to assist in "managing and monitoring" acti\ities in the OMA. 

4. Configuration Status Accounting 

Configuration accounting refers to the process of maintaining a record of 
exactly what parts are in and what changes ha\'e been made to a particular item 
of equipment. Changes or modifications to aeronautical equipment are directed 
by what are called technical directives (TD) issued by NAVAIR. When changing 
components, knowing the particular configuration is critical to the successful re¬ 
pair. This subsystem was intended to automate the process of keeping config¬ 
uration records for all aeronautical equipment. 

5. Personnel Management 

Knowing who is assigned to an acti\ iiy, their qi alifications. and the billet 
they occupy is essential to ensuring the right person is tasked to perform a par¬ 
ticular job. This subsystem was intended to "collect and maintain specific per¬ 
sonnel data for both military and civilian personnel assigned to an organization." 
[Ref. 46; p. 9] and thereby facilitate assigning the right person to each task. 

6. Asset Management 

This subsj'stem was essentially an in\cntory system for all aircraft and 
equipment assigned to an actixity. Particular attention was gixen to the Indixid- 
ual Material Readiness List (IMRL) and the Aircraft Maintenance Material 


Readiness (AMMRL) Program. Today, the Suppt)rt Equipment Resources 






Management Information System (SERMIS)i7 is performing some of this func¬ 
tion. 

7. Local/Upline Reporting 

This subsystem was to serve as the interface between other systems and 
NALCOMIS/OMA. It was to collect and accumulate information and then 
provide summarized reports to local management. In addition, higher authority 
reporting requirements of the NAMP would be satisfied by this subsystem. [Ref. 
46: p. 10] 

8. System Support 

"Communication between organizations...through the maintenance of on¬ 
line messages." [Ref. 46: p. 10] was to be handled by this subsystem. This is what 
is now called electronic mail (E-mail). This ser\ icc would haNe been pro\ ided to 
all organizations linked to NALCOMIS. 

9. Data Offload/Onload 

This subsystem was to provide the means to extract enter data about 
aeronautical equipment that was being transferred or received. An OM.A has no 
need to maintain the maintenance history for an aircraft no longer in its custody. 
Similarly, the history of an aircraft newly assigned to the OMA needs to be added 
to that unit's data base. Rather than enter it by hand, this system allowed the 
data to be entered electronically. 

17 As the reader wUl recall from "III. IM ORMA I ION S^ S I IiMS " on r.aee 17 SI RMIS 
is a system to ;iid in managing support equipment at all aviation acti\ities in the Navy. 
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10. Technical Publications 


The technical publications necessary to maintain modern aircraft are \o- 
luminous. Maintaining an inventory of ail of them, and where they actually are 
located is a job to which many people have been dedicated. This subsystem was 
intended to automate that herculean task. 

11. Summary 

NALCOMIS was an attempt to develop an information system, all at one 
time, as one overall project, to perform all of these functions. Trying to do it all 
at one time was, and still is too ambitious an undertaking. The details of just one 
function, flight hour accounting, are enough to keep several people busy ad 
infinitum with configuration management after deployment, not to mention the 
implementation itself. To realize the comple.xity of the procedures we are trying 
to automate, consider that Volume V of the NAMP [Ref. 45] is a document of 
over 700 pages that describes how the Maintenance Data System (MDS) works. 
More significantly, it specifies in laborious detail how to fill in the \ arious forms 
used as source documents for the MDS. 

We should learn from difficulties associated with the N.-\LCOMlS effort 
and not try to accomplish too much all at once. "The only unforyivah/c failure is 
the failure to learn from past failure." [Ref. 4; p. 6] ,A.ny project for DMAs (in¬ 
cluding OASIS) should either be kept small, or di\idcd into smaller projects and 
implemented one at a time. 

C OASIS MODULE DESCRIPTIONS 

The modules proposed for O.ASIS arc similar to those once proposed for the 
now defunct NALCOMIS OMA (at least defunct as originall\ en\isioncd (Ref. 
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51]), but arc organized to be more consistent with an OMA's primary goal: opti¬ 
mum management of human, monetary and material resources. They are pre¬ 
sented hierarchically in Figure 5 on page 67. 

Without people to operate and maintain them, aircraft will not fly, therefore 
those modules dealing with human resources arc addressed first. In view of cur¬ 
rent events in the world, and the much discussed "peace di\ idcnd', the second 
priority is monetary; thus those modules are described next. Third, the modules 
that are probably the most difficult to develop, those that address the manage¬ 
ment of material, from aircraft to piece parts, are described. Fourth will be a 
brief description of the utility functions that may be needed. 

1. Human Resources 

The first area to be addre.sscd is human resources. This is comprised of 
two modules. First is the Personnel Management Module that focuses on the 
information needed to obtain necessary people, and how to assign them once they 
ha\e arri\ed. Second is the Training and Qualifications Module that focuses on 
all the records necessary for the Assistant Maintenance Officer to effectiwly 
manage the personnel assigned and their training and qualifications. 
a. Personnel Management Module 
An OMA requires a variety of people of \arious rates (work spe¬ 
cialty), paygradcs (seniority), and training (skill). The "ideal" mix of people is 
specified in the Squadron Manning Document (SQMD), which is dc\eloped early 
in the procurement of the aircraft weapon system from the Planned Operating 
En\ironment (POE) statement for each acti\iiy. The Na\al Militar\ Pcrsimncl 
Command (NMPC) assigns real people to each activity to fill the billets' speci- 
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Figure 5. OASIS Hierarchy of Modules 


ficd in the SQMD. Those assignments are made according to priorities that 
change as supply, demand, and operational commitments change. In a perfect 
s_\stem e\ery actisity would ha\c all the people specified in its SQMD. That 
howcNcr is seldom the case. Usually ha\ ing just the "right" mix of talent and the 
right number of people requires dose liaison between the personnel officer (in 
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reality, usually the personnel chief) of the activity, the Assistant Maintenance 
Officer (AMO) of the activity, the next higher personnel office (usually the func¬ 
tional wing), and NMPC. It involves negotiation, detailed knowledge of the as¬ 
signment system, and most importantly, extensive knowledge of the real skills of 
the people in the OMA, how long they will be in the OMA, and what the future 
commitments of the OMA really are. The entire range of knowledge required by 
the AMO is not gained overnight. To be effective in obtaining the people an 
OMA needs from the personnel distribution and assignment system requires 
years of working in the system, OR someone else with those years of experience, 
i.e., an expert, who can (and will) help and teach you. 

Once the people have been obtained from the personnel system and 
ha\c actually arrived at the OMA, there is the problem of managing specific billet 
assignments both within the OMA and to various detachments. The initial as¬ 
signment is usually based on the billet to which the individual was ordered, the 
indi\'iduars past training and qualifications, and the immediate needs of the 
OMA. Subsequent assignments arc based on what the managers have learned 
about that indis idual's real skills, and the specific needs of that OM.^. 

This module is an area where both a decision support system and an 
expert system could be beneficial. The internal assignment problem is fairly 
straightforward and may lend itself to a DSS solution based on a set of models 
with constraints included. The problem of obtaining personnel in the first place 
may be best solved using expert system techniques. The rules of the personnel 
assignment system now contained in assorted instructions could be encoded in a 
knowledge base; the specifics of the acti\ity's personnel assignments wi>uld be 






contained in a data base; and the knowledge contained in the minds of the experts 
now in the fleet could be extracted by a knowledge engineer and encoded in the 
knowledge base as well. *8 Assigning people once they ha\e arri\'ed does not 
necessarily require an expert system, but in the process of getting them there in 
the first place an AMO with little knowledge of the Navy personnel system could 
benefit from expertise leveraged in the form of an expert system. The analogy 
between maintenance managers and information systems applies again. Mainte¬ 
nance officers are not personnel system experts. Yet they are tasked with using 
that system to achieve the goals of the OMA. Providing them "expertise" in the 
form of an expert system could significantly reduce the time they must spend 
learning the personnel system before they are able to use it effectively to the ad¬ 
vantage of their OMA. 

b. Training and Qualifications Module 
Within an OMA. two of the Assistant Maintenance Officer responsi¬ 
bilities are to "Establish and coordinate the department training program" and 
"Obtain school quotas to support training requirements." [Ref. 10: p. 4-10] As 
with the technology associated with information systems, aircraft technology has 
also made great advances. Maintaining aircraft is impossible unless people have 
the appropriate skills. Sources of those skills include Navy training schools, gen¬ 
eral maintenance training, in-service training, aviation maintenance management 
teams, and manufacturer's technical representatives. Means of measuring train¬ 
ing range from individual testing such as in the Maintenance Training Improve- 

IS riic data base for matching an activity s Manpower Authorvation (MI’Ai to the actu;d 
personnel a^^i^ned is eurrentl\ being desiinied as a thesis project at Naval I’osteraJuate School |Ref. 
52 |. 
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merit Program (MTIP), through summaries of training accomplished, to the final 
measure, sustained aircraft readiness. Closely coupled to training is the need to 
track various qualifications. Examples include swim qualifications, specific safety 
training, welding certifications, and other one-time or periodic qualification type 
requirements. The paperwork documentation required to manage the training 
effort is tremendous. For example, this author, in one month has had to per¬ 
sonally review a 10-20 page report on each of nearly 150 people in his depart¬ 
ment. All of that information is already in electronic form; in fact the reports 
were printouts from the A\iation Training Support System-Phase 11 (ATSS-11) 
system. Therefore, the training module of OASIS should provide a transparent 
interface to training records that are already kept electronically in ATSS. 

A micro computer-based system to manage and track the training re¬ 
quirements listed aboxe was under development at NAS Miramar in 1987-1988. 
When the author left Fighter Squadron Twenty-One (VF-21) in 1988. this system 
was in use at VF-21, VF-154, and AIMD Miramar. It or a similar system could 
be used as the basis for the module to help AMOs manage training. 

2. Monetary Management 

The second area to be addressed is monetary management. This is com¬ 
prised of two modules. First is the OPTAR Record-keeping Module that focuses 
on the information needed to manage the funds OMAs arc authorized to obligate. 
Second is the Requisition Records Module that focuses on the records neccssarx 
to keep track of all the items ordered and receixed by the OM.V. 
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a. OPTAR Record-keeping Module 
OMAs are required to keep a record of all funds they ha\e been au¬ 
thorized to obligate and of those obligations. These records are usually kept 
manually in the OPTAR log (NAVCOMPT 2155). The specific detailed in¬ 
struction for correctly maintaining the OPTAR log are found in Na \7 Staff Of¬ 
fice (NAVSO) Publications 3006 and 3013 [Ref 10; p. 6-136]. If those 
requirements were automated then much of the time spent finding and correcting 
errors, usually simple arithmetic errors, and balancing the OMA's records with 
those of the "official" records of the Fleet Accounting and Disbursing Center 
(FAADC) could be reduced. Processing the transmittals (NAVCOMPT 2156), 
Summary Filled Order Expenditure Difference Listings (SFO EDLs). and 
monthly Budget OPTAR Reports (BOR) could be streamlined and made more 
accurate by automating the necessary procedures. Once the data is in electronic 
form, additional potential benefits include correcting erro'^s at the point of entry, 
automatic upline reporting, and the ability to present the data in a \ariety of 
formats, even pictures, i.c., graphs, for upper level management (usually not ex¬ 
perts in the subject). At least two activities the author is familiar with arc using 
a simple spreadsheet package to accomplish this now. The problem with their 
applications is that they were developed by people who have since left the activ¬ 
ity. Now, when problems occur (and they will), or changes are required (and thev 
will be), these activities will cither revert to the manual way of record-keeping or 
will find someone who can spend the time learning the application and correcting 
the problem or making the change. 
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b. Requisition Records Module 

NALCOMIS Phase II includes a terminal for most OMAs that links 
them to their local supply activity. This has proven of great value to maintenance 
managers. It is used to order parts, to inquire about status of previously ordered 
parts, and to verify in or out of stock situations. Stock information is critical to 
a maintainer. If the part is essential, one of the alternatives for obtaining the part 
(if it is not available from supply) is to take it out of an otherwise not flyable 
aircraft. "Cannibalizing," as this process is called, requires double the normal 
maintenance effort. Instead of removing and installing one component, two are 
removed and installed. Three components are now exposed to potential damage 
from the removal and installation process, rather than the two had 
cannibalization not been necessary. By knowing the component is "on-the-shelf" 
and "ready-for-issue" (RFI), a maintenance manager can minimize unnecessary 
cannibalization actions. OASIS, either through NALCOMIS Phase li or other 
means, will provide a means of obtaining this information. 

An additional benefit of obtaining such parts information is the pos¬ 
sibility of maintaining an automated .equisition logbook. As part of the ordering 
process, where component information is already a\ ailable electronically (through 
NALCOMIS Phase II), capturing that information and loading it into a local 
OMA data base would be of great benefit. Part numbers, stock numbers, item 
description, and time ordered are the type of data that would no longer ha\ e to 
be re-entered every time an item is ordered. The hand-scribed (and sometimes 
illegible) logbook now required could be replaced by a clearly readable and un¬ 
forgetting automatic one. 
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3. Material Management 

The third area to be addressed is material management. This is ct)m- 
prised of four modules. First is the Flight Activity Module that focuses on re¬ 
cording and using information about flights. Second is the Maintenance .Activity 
Module that does the same for maintenance actions. Third is the Maintenance 
Scheduling Module that addresses determining the optimum schedule for com¬ 
pleting repairs. Fourth is Asset Management Module that addresses the in\en- 
tory management of OMA assets. 

a. Flight Activity Module 

This module collects the raw data, specifically flight hours, used to 
maintain the logbooks of aeronautical equipment. One of the functions of this 
module of OASIS will be to pro\ ide an automated logbook. Current procedures 
require man\’ calculations to properly remo\c and install equipment in an air¬ 
craft. and once installed, to account for the operating time of that equipment. 
B>' automating those procedures, many of the hours this author has witnessed 
(and spent) finding simple arithmetic errors can be a\()ided. Adiiitionallv. since 
the data is kept electronically, the only time a paper cop_\ wouki he needled would 
he when the equipment is transferred, or when signatures are rei.juire(.i. That 
paper cop> couki, at least for now. be an e.xact replica of the logbook forms cur- 
renth usetl. This could change in the future should the need for the paper form 
he remo\ed. This module would be used to provide MCCs with up-to-the min¬ 
ute status of any of the aircraft under their care. 

Might hours accrued b_\ a component are one of the ua\s of deter¬ 
mining when to perform scheduled maintenance of aeronautical ccjuipment. 







Collecting that information as it occurs has a significant impact on c\en simple 
maintenance actions like an oil sample that may be due every ten hours of oper¬ 
ation. Most OMAs have devised some way of keeping the MCCs aware of which 
components are coming due for a particular prc\entati\e maintenance action. 
The terms "Time since new sheet", and "Time sheet" are used to describe these 
end-user dexeloped information systems. Some are automated, and some are still 
manual. All provide MCCs with a single sheet containing the time remaining 
until the ne.xt required preventive maintenance actioni^. 

Configuration accounting is one of the functions of aeronautical 
equipment logbooks. Accordingly that function should be performed by the 
module that contains the automatic logbook. The data necessary to maintain an 
accurate configuration for all equipment will come from the VIDS M.A.F data 
representing technical directive compliance when tnat data is collected in the 
Maintenance Activity Module (discussed in ‘*b. Maintenance Activitv Module" 
on page 75). As parts arc removed and replaced on aircraft or other aeronautical 
equipment, the data entered to record those actions would automatically update 
the configuration records for the equipment. 

The computer aided N.^VFLIR data entry svstem (C.-XNDFS) is a 
micro computer-based system that performs the flight data collection function, 
but with the intention of providing the NAVFLIR data into an elect’onic form 


l'> .Some of these sheets present the information on an accruini: tune basis. What is printed 
is the amount of time since the previous maintenance action occurred. This means that the \K'( 
must perfonn some arithmetic to arrive at tlic due" time of the next action. .Another !.\pe counts 
down to zero Ihe times listed on the time sheet are the amount ol time reinainine until the 
specified action must be perfonned. Most of these reports arc produced once a d.t>. and the M( (' 
periorms simple arithmetic throuuh the day to update the figures on hi' sheet 
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to Data Services Facilities (DSFs) to upload into the AV-3M system. CANDES 
was born in the spring of 1989 and first tested in November 1989 [Refs. 53 and 
54]. At last report [Ref. 54], it is a success at all sites where it has been fielded, 
and plans to install it at additional sites^o are being implemented. CANDES 
could be expanded to fulfill other flight hour related or dependent functions and 
become the Flight Activity Module of OASIS. 
b. Maintenance Activity Module 

The maintenance history of aircraft, both an individual aircraft, and 
an entire type, model, series (TMS) of aircraft, can be \'ery valuable to main- 
tainers. If there is a sufficient history of equipment failure, then future failures 
can be predicted with a specified Ic\-ei of confidence. If MCCs had access to such 
data they could make better educated decisions about the likelihood of a partic¬ 
ular part being the cause of the current problem facing them. Another use of 
historical data is planning which parts and how many of each to take on a 
detachment. If two widgets fail every week, and the detachment is one week, 
then taking two widgets would be appropriate. The same parts usage data is used 
bs' procurement acti\itics to decide how many of each part to buy for a gi\en 
period of time. The means to obtain historical data must be part of this module. 
»..urre'''t data must be collected as it is generated by current maintenance actions. 
Additionally, historical d "a may be available from the AV-3M or N.ALD.'X sys- 

20 At this writing:, which Navy activits’ will be the coiifiL'iiration manager and who will pro\ ide 
post deploNinent ssstems support lor ( AN'II S has not been decided this means that when (.ind 
if) ( ASni S transitions Irom the Naval .-Xviation Maintenance Support (fflice (NAMSO) proto¬ 
type to an implemented s>stem, there may be no support 
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terns. A user-transparent retrieval of historical data from those systems is essen¬ 
tial. 

Collection of data about maintenance actions as they occur must be 
a priority. Each aircraft has its own "personality", or failure tendencies, and 
quick access to data about an aircraft's past failures can sometimes give indi¬ 
cations about current problems. Additionally, monitoring trends, now done 
laboriously by quality assurance personnel reviewing individual VIDS MAFs, 
could be automated. Some pre-defined trends could be tracked on a regular ba¬ 
sis, such as how many reported failures could not be duplicated during trouble¬ 
shooting. Other trends could be provided on an ad hoc basis. 

Once the data is in electronic form, it can also be used to satisfy up¬ 
line reporting requirements. Readiness statistics in the form of mission capable 
and full mission capable figures could be calculated automatically in accordance 
with both the NAMP and AV-3M system which monitors the full twenty-four 
hour per day capability, and the Aircraft Material Readiness Report (AMRR) 
which pro\idcs a "snapshot" of aircraft status (typically at the start of daily fight 
operations). 

One of the forms used to collect data is the VIDS MAF. It contains 
o\cr 50 blocks of different data elements, with over 200 spaces for data. The 
VIDS MAF has been limited to one page for years in an effort to minimize the 
paperwork as well as to not o\crwhclm those who must fill in the forms. To that 
end. associated with each block is a set of codes used to describe the maintenance 
action that occurred [Ref. 45; p. 6-11]. If we go to a computerized \ersion ofdata 
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collection, the arguments for one page become less compelling^!. The ease with 
which windowing22 is used in today's technology would allow the presentation to 
the user of only that information required at that particular stage in the mainte¬ 
nance action documentation process. The necessary codes could be displayed on 
demand. Another option would let the user pick the correct code from a list on 
the video terminal screen, thereby eliminating most of the guessing, typing, and 
tianscription errors. A computerized version of the VIDS MAF would also allow 
more descriptive information in the write up of the actual problem. The point is 
that even though more complete and accurate data could be collected, each user 
would have to deal only with that portion of the data that applied to him her. 

'W'e may not be able to do away with paper entirely, since there will 
remain the need for signatures at some points of the maintenance c\cle. That 
signature requirement could be satisfied if we had the data collection system print 
the signature part of the VIDS MAF whene\er someone must actually affix 
his her signature. There may be other alternatixes to signatures, and these need 
to be considered and e\aluated. If weaning maintainers from their VIDS board 
pro\cs too difficult23, then ha\e OASIS print a form (which could be adapted to 
the preferences of the specific OMA) for the VIDS board-just do the data entry 
at a terminal and get the data at the source. Benefits of automation include more 

21 This docs not imply that wc should collect more data, only that we c;m now use a sinde 
screen display for each step in the maintenance process, and that the one pace hmil should he re¬ 
evaluated in light of using computen/ed data cntr> versus a paper form. 

22 "Windowing" refers to the ability to overlay a second (or more) screen of infonnation. e\en 
including the running of another application, on top of the one currently in use. 

23 After an unbiased comparative analssis of both the X'lD system and the computer b.tsed 
system, we may find that the \'IDS has advantages wc are unwilling to gi\e up 1 wo sueli ad\an- 
tages are that it is not subject to electric.al power failures and that it is alreails well known and un¬ 
derstood throughout the lleet. 






accurate data: maintaincrs won't be "remembering" which code to use in which 
block, but will be able to pick the right one from a list in front of them. No more 
legibility problems at the DSF, no more typographical problems, at least within 
the allowable characters for a given block, and fewer keypunch errors are all 
likely results of collecting data in electronic form. 

c. Maintenance Scheduling Module 

An expert system to assist Maintenance Control Chiefs in allocating 
their scarce resources optimally among all the competing short, medium, and long 
term objectives would be the key element of this module. Such an expert system 
was found to be feasible by McCaffrey in 1985 [Ref. 6: p. 122]. As pre\iously 
discussed, the supply of true experts in the field of maintenance is below the de¬ 
mand. so the need to leverage those we do ha\c is great. E\en though export 
systems ha\e reached the commercial market since McCaffrey's work in 1985. 
their use by DOD the operating actixities is low or non-existent. Therefore, a 
particularly productive project for the Naxy's graduate students at the Naxy 
Postgraduate School xvould be to apply ES techniques to helping all maintenance 
chiefs be more effective. The first part of the problem to be addressed should be 
something readily definable, such as some of the scheduled maintenance require¬ 
ments. Later iterations could add other aspects, un-scheduled maintenance, for 
example. In that xvay, OMAs could benefit from having a "consistent expert 
ax ailabic at any time. 

d. Asset Management Module 

Although assigned to the material control work center (except for 
publications), these functions cross all work center, dixisinn, tind deptirtnieni 
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boundaries and are therefore grouped into the one module. In effect this is an 
automated inventory system for all OMA assets. Keeping track of all an OMA's 
assets is a very time-consuming repetitive task that requires meticulous attention 
to detail Such tasks are ideally suited to automated record-keeping. OMA assets 
include everything from janitorial equipment and office supplies to expensive test 
equipment and computers. The technical publications library, which includes all 
the repair manuals as well as Naval instructions, is included as are IMRL 
equipment and common hand tools. 

The tool control program requires positive accountability of all tools 
lest they find their way into the wrong place and do damage (known as foreign 
object damage or FOD). To achieve such accountability, accurate and detailed 
in\entory records of e\cry tool are imperati\e. The tool boxes for these tools are 
arranged with some means of \isually ascertaining in just a few seconds that ex- 
cry tool that belongs in tha container is there or that its location is known. .A 
future enhancement to this module, as technology inexorably advances, would be 
to add the shadow diagrams for every tool box to the automated invcntorv' re¬ 
cords. This would allow the tool control plan for each aircraft to be distributed 
electronically, rather than on paper. 

The master inventory of the activ ity s aircraft would also be kept by 
this module. Flight packets would be accounted for and even "signed ' for by pi¬ 
lots through this module as they signed foi their aircraft. W’hen the technical 
publications library is distributed via Compact Disk-Read Only Memory 
(CD-ROM), the ease with which MCCs couki search for and find the obscuie 
detail about a component, proceilure, or requirement would he greatly enhanced. 








4. System Utilities Module 

This module will perform a number of diverse functions common to the 
other modules. The list is not exhaustive: in fact, other general utility functions 
will undoubtedly be desired by the end-users. The minimum starting set of 
functions is described in the following sections. 

a. Receipt and Transfer 

Receipt and transfer of equipment would be a function of this mod¬ 
ule. Any time an item was received, data from its logbook would electronically 
be added to the OMA's inventory via this module. Upon transfer; just the re- 
\erse would occur. Any necessary paper copies would first be printed and then 
the electronic logbook would be transferred, either directly \ia communications 
link or by diskette. This process would apply to aircraft in particular but also to 
all other aeronautical equipment, particularly support equipment and IMRL. 

b. Communications 

A telecommunication system would connect all parts of the s\stem. 
The interfaces to other systems would be transparent to the user because of 
standard interface programs contained in this module. Also included would be 
an electronic mail (E-Mail) system. This would operate on what would effccti\el\ 
be a local area network (LAN) within the OMA. The telecommunications capa¬ 
bility would allow readiness reports, for example, to be prepared b> the analyst, 
reviewed by the Quality Assurance Officer, the .-yssistant Maintenance Officer 
(AMO), the Maintenance Officer (MO), the Operations Officer (OPSO). the 
Executive Officer (XO), and the Commanding Officer (CO) and then to be sent 
to higher authority without ever being produced on paper. 





c. Database Management and Maintenance 
All database management and maintenance functions would be per¬ 
formed by this module also. Periodic backup of the OMAs database would be 
automatic. Any batch processing such as periodic standard reports would be 
handled within this module. In effect, this module would be the "traffic cop" for 
data flow within OASIS. The precedence procedures to prevent two people from 
trying to change the same data element at exactly the same time would be en¬ 
coded here. The database management system must include the capability to 
support a wide array of ad hoc queries. A minimum requirement is including the 
standard query language (SQL). 

5. Summary 

The module descriptions presented represent the conceptual organization 
of OASIS. It should be readily apparent that de\eloping a single system to per¬ 
form all these functions is a demanding task. In fact, it is simply too big and too 
complex to accomplish in one system development effort, as the history of 
NALCO.MIS shows. A project of this size will take too long and will make 
keeping up with changes e\cn more difficult during dcxelopmcnt because the 
longer the de\ek)pment time, the more changes are likely to occur. Such an ef¬ 
fort, trying to de\elop and deli\er c\erything all at one time. is. howe'er well- 
intentioned, doomed to fail. 

D. I^IPLEME^TATIO^ PLAN 

This section will address some general systems implementation issues as they 
relate specifically to 0.-\SlS. and then outline the prcliniin;ir\ OASIS implemen¬ 
tation plan. The plan is onl> preliminary, since it w ill need to be in much greater 
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detail than possible here. Additionally, the plan, once formalized will be subject 
to frequent change. Another factor is that information systems planning has 
advanced so far technologically that even the strategic planning process is now 
automated. At least the documenting of the process and resulting plans is auto¬ 
mated. (We haven't automated thinking yet). The value of such automated tools 
is significant particularly to a project such as OASIS which is intended to e\olve 
and change as each module is added and as the operating en\ironmcnt changes. 
Automating the record-keeping, documenting and plan generating will both ease 
the administrative burden and reduce the potential for overlooking something 
when making changes to the project specifications and plans. Those who actually 
de\elop O.A.SIS should take advantage of the automated development tools 
axailable today. 

1. Related Issues 

There are se\eral issues related to the de\eIopmcnt of any information 
system for a\iation maintenance. They include identifying the customers of the 
system, deciding whether to develop the system in-housc or contract for the de¬ 
velopment, de\cloping a data dictionary directory, deciding which hardware and 
software to use, identifying and specifying interface requirements, identifying 
potential applications for expert systems, deciding whether to follow a traditional 
or prototyping approach, performing a cost-benefit analysis of the project, and 
evaluating previously proposed systems for inclusion in OASIS. 
a. OASIS Customers 

Many people in aviation maintenance need infurmation about read¬ 
iness. If O.ASIS is to satisfy their needs, identify ing those customers explicitly is 
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essential. To any organization, customers fall into two groups, internal and e.x- 
ternal. Internally, the customers of OASIS are the professional maintenance 
managers who have spent years learning their profession, the Maintenance Con¬ 
trol Chiefs, and professional maintenance officers. Other beneficiaries include 
aviators assigned as Maintenance Officers and Division Officers, the quality as¬ 
surance division, and material control and maintenance administration work 
centers. By virtue of the benefits accrued by those professional maintenance 
managers, the whole activity will benefit from better overall performance and 
readiness. None of these users will really care what the system is called or how 
they got it, as long as it helps them do a better job. 

Externally, the customers of OASIS are all the other systems with 
which it must interact and those higher authorities to which the OMA pro\'ide 
both raw and summarized data. Some of these ha\ e already been identified, but 
an exhausti\e list should be prepared that includes a detailed description of the 
technical hardware and software interface requirements for each. 

b. In-house Development versus Out-house Development 

The question as to whether OASIS should be developed within the 
Navy or outside the Navy by a contractor, must be thoroughly analyzed and 
finally decided. There are benefits to both. By doing the development in-house, 
we have control of the entire system development, do not have to learn the av i- 
ation maintenance business, and do not have to worry about a contractor not 
going to sea to maintain the system he just delivered. On the other hand, we must 
maintain the information systems expertise to develop, implement, and support 
the system after deploym.cnt. In this era of fewer funds, doing the development 
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with people who are already "on staff" avoids the cost of hiring new people. 
However, those same "on staff" people must devote time to system development 
that they would normally devote to other duties. The real impact and cost of 
both options needs to be investigated. One of the things strongly fa\oring in- 
house development is the growth of end-user development. 

(I) Managed End-user Development. End-users (the internal 
customers) have little or no idea of what can be done with current information 
systems. They are aircraft maintainers, not information system developers. 
What is needed is to somehow expose them to the possibilities. The best way to 
do that is to provide them something they can use, i.e., something that will help 
them do their jobs, while at the same time sparking their imagination about other 
functions an IS can help them accomplish more effectively. Those ideas can then 
be incorporated in the next release of OASIS. This procedure is much the same 
as followed by marketers of major software products, and is also part of the phi¬ 
losophy advocated by Total Quality Management, i.e., continual improvement. 

For the same reason, i.e., end-users have little or no idea of 
what can be done with current IS technology, to expect them to be able to define 
their requirements at the very beginning of a project in a manner from which an 
IS could be developed is expecting too much. To do so is to invite the chance of 
missing out on an opportunity to take advantage of 1) software and hardware 
technology advances that occur during a long development, and 2) end-users' 
imaginations that can be stirred by having a sample, i.e., a prototype. Therefore, 
an effort to manage the end-users' developed applications in conjunction with 
OASIS prototypes is essential. In reality, some of the end-user's applications may 
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very well form the beginning of OASIS modules, if not becoming the modules 
themselves. 


(2) NAMD's Functions. The Naval Aviation Maintenance Office 
(NAMO) has several responsibilities specified in the NAMP. Among them arc 
"Developing and maintaining management information systems which directly 
support the fleet," and "Planning, design, development, implementation, and 
support of all information systems'decision support systems which support the 
total life cycle of aeronautical equipment." [Ref. 9: p. 4-4] These responsibilities 
are cffecti\cly a charter for NAMO to bring all fleet aviation maintenance and 
support information systems under NAMO's purview. 

(a) Central Design Acti\ity— In accordance with its 
N.AMP charter, NAMO should be the Central Design Acti\ity (CD.A) for all 
a\iation maintenance information systems, from the NaNal ,A\iation Logistics 
Data Analysis system (NALDAj and the AV-3M to OASIS. As CDA, NAMO 
would ha\e the unique opportunity of being the keepers of both the NAMP and 
the information s\stcms that support the NAMP. In other words, the mainte¬ 
nance experts who manage the NAMP would ha\e the same chain of command 
as the information professionals who proxidc the information sxstems for the 
NAMP. As two different groups of professionals with the same goal, i.e., support 
to the fleet, such a relationship can have only synergic benefits. The parallel to 
the relationship between a\iation maintenance and a\iation supply is inescap¬ 
able. The maintenance supply relationship resulted in the .loint .'Xxiation Supply 
Maintenance Material Management school being dc\eloped. It is time for ;i 
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similar relationship between experts in maintenance and experts in information 
systems to be established. 

(b) Confipnradon Management— NAMO can and 
should, under the authority of its charter, act as a clearinghouse and configura¬ 
tion manager for end-user developed applications. Of particular interest are 
those that are not (yet) part of OASIS, but that might be if benefit to OMAs 
other than the one that de\cloped the application. In response to a request from 
NAMO, an OMA would send NAMO a copy of their application. N.'WIO 
would be responsible for verifying that it complied with the NAMP and other 
applicable instructions and standards. NAMO would then make any changes 
deemed necessary, e.g.. superimpose a standard user interface. Finally. NAMO 
would make a compiled version^-i available to all other OMAs cither by electronic 
bulletin board, or by mailing diskettes. The original de\eloper would submit 
preliminary support (both user and maintenance) documentation in electronic 
form, which N^MO would update as it updated the code and subsequently pro- 
\ ide to all users as part of the product. This whole process should occur elec¬ 
tronically. Because of the \olumc and \ariety of the cnu-Mser applications. 
NAMO would ha\c to filter the responses. In other words, if 2c applications to 
automate the logbook were received, NAMO would choose or combine features 
from different applications into a single version of the automated logbook which 
would then be supported by NAMO. (N.AMO may not provide the actual post 
deployment software support, but would coordir.cite. as the configuration man- 

24 A coi.ipiled version is one that has hecn reduced to actual machine instructions, and is no 
longer in the onginal programming language (called the source code|. 
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ager, the PDSS efforts. The actual support may be provided by Na \7 software 
activities, NPS, or contractors.) The availability of these application programs 
should then be made known to all OMAs. This could be initially done via Naval 
message, with subsequent follow-up articles and listings in professional aviation 
maintenance magazines such as MECH and CROSSFEED. Even possible, but 
unlikely in view of expected funding limits, is that a separate publication could 
be started to advertise the applications available as well as to provide articles of 
general interest to aviation maintenance computerized information systems users. 
At the \ery least, an electronic bulletin board should contain, if not the actual 
programs and documentation, a list of what is available and how to get them. 

i'3j Participation. NAMO should solicit users' input as to the 
first module to be de\eloped. Those who should be consulted include the OMAs 
(the end-users), Type Commanders, Fleet Commanders, the Aviation Mainte¬ 
nance Officer .School, and the current NALCOMIS office (PMA-270). Once the 
first module has been selected, developed and fielded, the next one should be 
chosen and the process repeated. As each module is de\eIoped and feedback is 
rccci\ed from the end-users, priorities may actually change from those proposed 
in the preliminary implementation plan. If that is the case. fine. There is nothing 
sacred about the preliminary implementation plan for OASIS, 
c. Data Dictionary fDirectory System 
A simple but potentially very time-consuming issue is that of the spe¬ 
cific data elements an activity (and OASIS) will use. For example, a decision is 
necessary as to whether a social security number is nine digits separated by hy¬ 
phens. nine consecutixe digits, or some other arrangement of digits and symbols. 
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Another example is the format for a date. There are dozens of variations, from 
day month year, to a four or five digit Julian date. The MDS Validation Spec¬ 
ifications [Ref. 55], also known as the VALSPECS should be used to establish the 
initial data dictionary. As applications are developed, a data directory should 
be added so that the impact of changes proposed in the future could be assessed, 
as well as ensuring that those changes actually made are complete. Once the in¬ 
itial DD/ DS is established from the VALSPECS, the systems with which OASIS 
must interact should be assessed to 1) determine what if any differences exist, and 
2) build standard conversion modules to make data transfer among them trans¬ 
parent to the end-users. 

d. The Hardware-Software Decision 
Deciding which specific software and hardware OASIS will use 
should be left until as late as possible in the dexelopment cycle. Initially, for the 
prototypes, existing hardware and software could be made to suffice. Only when 
OASIS approaches full functionality should the decision about hardware and 
software be finalized. That way, the latest advances in both technologies can be 
made a part of OASIS. Of course, since the micro computers of today ha\e the 
capability of mainframes and mini computers of 15 years ago. assuming that 
OASIS will be based on a micro computer is a safe and logical assumption. The 
specific make, model and capabilities should be left until a better understanding 
of the functional and technical requirements is obtained through the de\ elopment 
of the first few modules. This of course implies that the first few modules will 
be required to work on the hardware and software already a\ailablc at most 
OMAs. 
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The question of which software package or combination of packages 
to use to develop OASIS must also be answered. This issue will have to include 
a decision as whether or not to standardize on one language (such as ADA) for 
all of OASIS development. Many application packages are available, from basic 
spreadsheet and database packages to more advanced and sophisticated fourth 
generation languages. These packages were designed to perform the same type 
of functions needed in some OASIS modules. Using them may reap the benefit 
of easy development, but may also incur the threat of poor or no support at some 
time in the future. ADA on the other hand, is the DOD directed standard lan¬ 
guage and therefore we have some assurance of long term support. Howe\er, 
using ADA would in\ol\e considerably more effort than using commercially 
a\ailable software application packages. It would also mean that all the appli¬ 
cations alrcad\- dc\eloped and in use would ha\'c to be re-written. \Vhate\cr de¬ 
cision is made will ha\e long term implications for both de\clopmcnt and post 
deployment support and maintenance of the system. This decision should not be 
made lightly, and in fact may require a study of its own. 
e. Interface Requirements 

The need for OASIS to interact with other information systems must 
be recognized from the outset. NALCOMIS Phase II. SU.-kDPS. U.^DPS and 
NALDA are four of those for which an interface must be developed. Since they 
most likely have different technical and logical requirements for interaction, each 
of them must be investigated and the interface requirements specified. This will 
involve such things as the format and order of specific data elements, as well as 
the technical specifications such as transfer rate. Once those requirements are 
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known, standard modules should be developed to be included with OASIS mod¬ 
ules sent to an OMA that must interact with any of those systems. For example, 
to link to NALCOMIS Phase II will require that the data conform to the 
VALSPECS, but also data transfer protocol must be specified. These are tech¬ 
nical details beyond the scope of this thesis, but they must be resolved for OASIS 
to reach its full usefulness to OMAs. 

/. Expert Systems 

All the fault isolation in the world will not fix the fault. Once a piece 
of equipment has failed, and the fault has been isolated, the real problem of al¬ 
locating resources to repair it begins. Resource allocation necessitates consider¬ 
ation of the OMA's goals and missions. Short term goals like today's flight 
schedule, medium term goals like next month's detachment to NAS Wherever, 
and long term goals such as the next deployment should all ha\e an impact on 
the allocation of resources. 

Expert systems hold significant potential to assist in scxeral areas of 
aviation maintenance and particularly that of resource allocation. Resource al¬ 
location is essentially what MCCs do. They consider the resources axailablc to 
them, e.g., time, people, funds, equipment and tools, compare those resources to 
their goals, and formulate a plan to achieve those goals. Leveraging the expertise 
of the most experienced maintenance chiefs for each type of aircraft has tremen¬ 
dous possibilities. The job of MC is just too complex. It requires too much spe¬ 
cific knowledge in too many areas for one person to be able to manage it all. This 
has been recognized by the division of responsibilities into material control, 
maintenance control, and maintenance administration, but e\en these dix isions 
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are becoming inadequate as managers arc overloaded with programs, data, & 
requirements. Most MCCs rely on other subject matter "experts" to help them 
when they need information about a specific area. This is to aid them in making 
decisions. What happens when such expertise is not available EXACTLY when 
it's needed? You 'punt' as it's commonly called, or make a wild guess. In aca¬ 
demic parlance you satisfice-pick the best guess you can and make do with it. 
Altcrnati\ely, you wait until the expert is available, which has all the potential 
drawbacks associated with a delayed decision, such as missing a launch or 
launching late. 

How can this problem be solved? Find a way to make the expert 
available to all who need the knowledge anytime they might need it. The cost of 
doing this with people, just in the sheer numbers, not to mention the cost of 
training and retaining, is obviously prohibitive. Furthermore, based on past ex¬ 
perience. in spite of the best intentions in attempting to accomplish this desirable 
objccti\e, we ha\e not been 100 percent successful. In other words, some OM.\s 
still lack the required expert. An alternative is to lexerage the experts we do ha\e 
in such a manner that they do not need to be there, on site, or e\cn ax ailable by 
phone. Here is where an ES can help. Expert systems are the means to Icxcrage 
our experts. 

Sexeral questions will ha\e to be answered for any expert system in¬ 
corporated within OASIS. They include: 

• Who will champion the project? In other words, who (or what office) will 
undertake to convince the people with funding to support dexelopmcnt of 
an expert system? 

• Who will be the knowledge engineers? Who will translate the experts' 
knowledge into an expert system? 
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• The knowledge engineers will likely not be in sufficient quantity to gather 
all the knowledge from the maintenance experts. Who will serve as appren¬ 
tice knowledge engineers, helping the knowledge engineers, and in the proc¬ 
ess become knowledge engineers themselves? 

• Who will be the maintenance experts from whom the knowledge is gathered? 
Will they be available? Can they be convinced of the need for an expert 
system, and thereby lend their full support? Will their bosses allow them to 
work on an ES development project that may detract from their performance 
of their normal duties? 

• Are the existing (or planned) databases sufficient for the needs of the ES, 
or will they have to be developed also? 

• Who will keep the database(s) in the ES up-to-date? 

• Who will provide the post deployment support for the ES? 

• Who will keep the knowledge base up-to-date? 

• Who will decide what knowledge will be included, and when changes to that 
knowledge base are appropriate? 


An ES will require as part of its database, the maintenance history 
of each aircraft. Whether this history is down-loaded from the .AV-3M system, 
or extracted from the Na\al Aviation Logistics Data Analysis (NAL OA) system, 
or is collected on site in a local database as part of the Maintenance Actixity 
Module, needs to be determined. An expert system can resohe uncertainty in one 
of two ways. Either the needed probabilities are encoded in the knowledge base 
or the ES extracts data from the database and calculates the probabilities as 
needed. Since the Maintenance Activity Module and the Flight Activity Module 
will hold much of the data the ES will need, they will ha\ e to be developed before 


or concurrent with the ES. 






g. Traditional Development versus Prototyping 

(1) Traditional Development. The traditional systems dexelop- 
ment life cycle as presented by Whitten, Bentley and Ho is a "generalized 

problem-solving approach...[that has]...eight steps or phases: 

1. Survey the situation. 

2. Study the current system. 

3. Define user requirements. 

4. Evaluate alternative solutions. 

5. Select new computer equipment and software (if necessary). 

6. Design the system. 

7. Construct the sj'stem. 

8. Deliver the new system." [Ref. 13: pp. 142-155] 

Note that this approach, in contrast to the information engi¬ 
neering (IE) approach described earlier, places emphasis on the current situation 
and systems first. (IE on the other hand, eschews deri\ing the new system from 
the old in favor of emphasizing the organization's information needs.) With this 
approach the end-users are mentioned or implied only twice, when defining their 
requirements and when deli\ering the system. One of the techniques used in the 
traditional approach to help define user requirements has been a prototype. 

f2j Prototyping. The best way to get user input is to let users see 
what is possible. Pro\iding them a quick and dirty prototype that shows them 
what is a\ailable would geneiate discussions about real requirements and nice- 
to-have requirements and would likely provide meaningful user input. This will 
also get people thinking about possibilities. Pro\iding a prototype of OASIS to 
all 400 plus OMAs is obviously prohibiti\e. However, a single one could he taken 
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to the major Naval Air Stations for demonstration and comment. The Wing 
(TYCOM) Maintenance Officer can host conferences of MCCs and MMCOs to 
present the idea and solicit input/feedback. Using a prototype to define and re¬ 
fine requirements is the best development method to use. A prototype is a rela- 
lively inexpensive way to make sure the early planning is correct, and thereby 
avoid some of the problems that have plagued other projects in their later stages. 

Another particularly telling point about end-users and proto¬ 
typing should be made. The end-user is an c.xpert in his field, not information 
systems or information systems development. By asking them what they want, 
we can expect only some generalities. So, we should take those generalities (since 
they are all we can get) build a prototype of what we think they want, and gi\c 
it to them to use and critique. As their needs begin to crystallize, so will the in¬ 
formation system to satisfy those needs. 

Turban [Ref. 22: p. 150] differentiates between two types of 
prototypes, throwaway and evolutionary. 

f3) Throwaway Prototypes. The throwaway prototype is built 
and used once. Its purpose is to get information from the users about the system 
they really en\ision. Once the requisite amount of information has been col¬ 
lected, the prototype is discarded. As Brooks says, 

The management question, therefore, is not whether to build a pilot system 
and throw it away. You will do that. The only question is whether to plan 
in advance to build a throwaway, or to promise to deli\cr the throwaway to 
customers. Seen this way, the answer is much clearer. Deli\ering the 
throwaway to customers buys time, but it does so only at the cost of agony 
for the user, distraction for the builders while they do the redesign, and a bad 
reputation for the product that the best redesign will find hard to li\e down. 

Hence plan to throw one awav; you will, anyhow. [Ref. 44: 

p. 116] 
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(4) Evolutionary Prototypes. Another approach to prototyping 
is called evolutionary [Ref. 22; pp. 150-152]. This is where a prototype is built to 
perform what are thought to be the most important functions and gi\en to the 
user to use and critique. Based on the user's critiques, the prototype is changed 
and returned to the user. This process of continually improving the system is 
repeated until the users agree that they have what they want. Then the system 
is integrated with others to form the "final" system25. 

An additional benefit to this approach is that as we attempt to 
put what they want, and how they do business, into a system we (and they) may 
find that the process they are currently using really does not work the way they 
think it docs and needs to be changed. Commensurate with re-thinking the cur¬ 
rent process, is the need for the system itself to be flexible enough to accommo¬ 
date the changes in the process that may come to light during development. 

(5) Pre-Prototype Survey. Before building a prototype the users 
must still be consulted about what they would like the system to do for them. 
Since the OMAs are so geographically dispersed (literally around the world) 
tra\ clling to each of them to personally gather their responses would be prohibi¬ 
tive. Therefore another way to get the initial desires must be used. .A sur\ey of 
all the OMAs, by Naval message or letter would proxide a starling point for 
building the prototype. There are a variety of questions that could be asked in 
such a pre-prototype surxey. They include: 

25 In terms of the entire life e\cle of the system, using the term final is ineorrect. since there 
will in fact be alterations. However, final is often used to refer to the version of the system that 
did or w ill e.xist when the .s>stcm reaches a p;irticular milestone in its life. That lersion is the final 
version of that phase of the system s hfe cycle. 
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• What decisions need the most support, or are the most difficult and require 
consulting an expert? (The goal of this question is to find out by simply 
counting the votes, which areas of maintenance would benefit most from an 
expert system.) 

• What would the MCCs would like to see automated? (This question is a 
wide open one, and may need to have a few examples to prompt answers. 
The level of response and specific answers could be used to assign priorities 
to the different modules of OASIS, expert systems included.) 

• How much and what type of support and training would they like. (Again 
examples would be useful to prompt responses, but this could be used to as¬ 
sess the level of post deployment support they expect.) 

• What is the opinion of upper management, specifically the CO and XO with 
regard to the ability, experience and performance of their maintenance or¬ 
ganization? (This question will provide a view of the "real" quality of the 
experts out there, and may also help identify those maintenance profes¬ 
sionals who should be tasked with being "experts" for the development of the 
system.) 

• Do COs. XOs, OPSOs, and MOs get the information they when they need 
it and do they have confidence in it? (This question accomplishes two goals 
if answered. First, the response will provide a measure of the "climate" into 
which we intend to place OASIS, i.e.. how rccepti\e the commands are to 
computers and automation. Second, it will provide us with a measure of 
what upper managers think is important. They too are customers of OASIS, 
expert system included, and if we build those modules that respond to both 
upper management and the MCCs, acceptance of the system will be greater.) 

• A question that could be asked of COs only is whether or not they would like 
to have more and possibly better "expert" help on call. WITHOUT the 
'stigma' of asking for help and hanging their 'dirty laundry' out? (This 
question is another one to assess the percei\ed need for more quality main¬ 
tenance professionals.) 

• What information is of most value to maintenance control chiefs, and do 
they get it when they need it, in a form they can use? (This would gi\'c an 
indication of which modules to build first, and which interfaces should be 
developed first.) 

• What equipment do the DMAs have now? This will invohe an inventory 
of the hardware and software currently held at each OMA. (This question 
would provide an indication of potential prototype sites, as well as an indi¬ 
cation of the additional equipment that will be needed to implement O.XSIS 
at each site.) 
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h. Cost-Benefit 

This project must eventually graduate from research project to de¬ 
ployed system. To do so it will have to be justified and funded. Therefore, 
NAMO, or whichever activity sponsors OASIS, will have to begin including 
OASIS in its budgeting process soon. In addition, a detailed cost-benefit analysis 
will have to be done. Rather than wait until the last minute and try to remember 
what various costs have been so that future costs can be predicted, do one now 
and kept it updated as the project progresses. Several methods of cost-benefit 
analysis are a\ailable. Payback analysis, rcturn-on-investment analysis, and 
present \ alue analysis are just three [Ref 13: pp. 796-802]. The best of these is 
present value analysis: the other two have limitations. The de facto guide in the 
Na\y is Economic Analysis Procedures for A DP [Ref. 56]. It prot ides \ cry ex¬ 
plicit "how-to" guidance for performing economic analysis of ADP systems. 

Some of the potential benefits of OASIS include increased readiness, 
more timely and accurate readiness figures, and better maintenance decisions at 
operating letels resulting in less waste, more effective parts usage, and fewer re¬ 
pairs being made by black box changing \icc true troubleshooting. Though dif¬ 
ficult to quantify, a reasonable attempt must be made. Estimating what an 
additional one percent impro\emenl in readiness costs will likely be necessary to 
help higher authorities determine the costs of increased readiness that will result 
from implementing OASIS. Costs are much easier to identify and include the 
obvious direct costs of hardware and software, as well as some not so ob\ious 
ones such as supplies, telephone calls, and postage that will be used during de¬ 
velopment. 
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Allen and McSvvain recommended value analysis be used to evaluate 
a DSS/ES [Ref. 7; pp 87-88]. Value analysis focuses on the minimum benefits to 
be achieved by a system in order to be considered successful. Ne.xt the maximum 
amount the user is willing to pay for each benefit is determined. Assuming that 
the costs are within limits, a prototype is then built. The value analysis process 
can be looked at as formalized intuition, but is still less rigorous than the 
cost/benefit techniques listed above. [Ref. 20: pp. 165-167] 
i. Additional Systems 

Proposals ha\c been advanced to de\'elop systems that would address 
various areas of aircraft maintenance management, but none of them has yet 
been implemented. Se\c-ral of them are: A\ iation Squadron Enlisted Training 
System (ASETS) [Ref. 57]; an expert system for assigning personnel to squadron 
detachments [Ref. 33]; an expert system for scheduling maintenance actions [Ref. 
6]; a decision support system expert system for maintenance controls [Ref. 7]; and 
a system now being proposed as a thesis project at Na\al Postgraduate School for 
matching an acti\ity's Manpower Authorization (MPA) to the actual personnel 
on board [Ref. 52]. 

2. Preliminary Plan 

If we apply the information engineering methodology to the OM.4 "busi¬ 
ness" we will find a pyramid with many small projects at the base. All of these 
can be developed under the umbrella of OASIS. This is when the crucial step is 
taken. As Mr. Finkelstein advocated in his presentation in June 1989, assign a 
priority to each of the small projects, and concentrate effort on de\eloping those 
small projects from start to finish, progressing from one project to the next in or- 





dcr of the assigned priorities The highest priority should be given to those 
modules that have been identified by the end-users, or those deemed by higher 
authority to have the greatest impact on accomplishment of the OMA's strategic 
goals. (Or, if necessary, the projects that will have the greatest visibility with the 
people controlling the funding.) 

One of the benefits of developing a modular plan to satisfy the functional 
requirements of an information system is that any module can be developed in¬ 
dependently of the others. Although a more detailed data analysis is still re¬ 
quired, the module organization presented here is based on data dependencies. 
The only module that may be dependent on another is one using ES techniques 
that require that a database be developed first (or at least concurrently). Such 
is the case with the proposed expert system in the Maintenance Activity Module, 
for example. It must have available aircraft historical data, personnel training 
and qualification data, fiight activity data, and asset status data to be of real 
value to MCCs. 

Applying the same priority stated in “C. OASIS MODUL.E 
DESCRIPTIONS’’ on page 65, ./C human resources modules should be devel¬ 
oped first, followed by financial management modules, material management 
modules, and finally the utility modr'e. However, visibility has a lot to do with 
a system's success with sponsors and acceptance by users. The more people who 
see and use a system, the higher is the likelihood that it will become accepted anil 
supported. Although in the long run personnel issues will have a dramatic impact 
on an OMA's ability to perform, those issues seldom receive the sustained visi¬ 
bility that aircraft readiness issues do. Accordingly-, the first modules that should 
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be developed are those that have high visibility in terms of aircraft readiness. 
Those modules are the Flight Activity Module, the Maintenance Activity Mod¬ 
ule, and the Asset Management Module. The expert system portion of the 
Maintenance Activity Module will require data from the Flight Activity Module, 
the Training and Qualifications Module, and the Asset Management Module, so 
those modules should be developed in parallel with the ES in the Maintenance 
Activity Module. Considering the fact that financial management is bound to 
be consistently important (particularly as funds become fewer and fewer), the 
Financial Management modules should be developed next. The utility module 
functions should be de\eloped as needed to support the rest. Finally the Per¬ 
sonnel Management Module should be developed. The benefit of the modular 
organization deserves added emphasis. Each of these modules can be developed 
independent of the others (with the sole exception of the expert systems), as long 
as it is developed under the umbrella of an oxer all plan that will make future 
integration of the different modules easy. OASIS is such a plan. 

Information engineering is the most promising development methodology 
to use, and is the most consistent with the modular framework proposed. Addi¬ 
tionally, taking the evolving prototype approach will allow a system to be dexel- 
oped that meets the real needs of the end-users, not the needs of the users as 
perceived by a systems developer. In short, build a quick and dirty prototype and 
get it out to the fleet (DMAs). Let the users propose changes and improxements. 
make those changes, and repeat the process until an acceptable level of stability 
is reached, and then go on to the next module. A good place to start xvould be 
with CANDES. It already has support and xisibility, is already being implc- 









mcntcd, and more importantly, is the data collection portion of one of the mod¬ 
ules (Flight Activity) recommended above for immediate development. The 
benefits of just collecting the NAVFLIR data at the source are becoming obvious. 
Results through January from the first test sites indicate that what used to be a 
10-20 percent error rate is now zero [Ref. 54]. The aircrew, or whoe\'er enters the 
flight data, aren't allowed to make errors. The errors are trapped right at the 
source. This allows all the people who were invohed in the post entry checking 
process to perform other tasks, or to do those other tasks better now that they 
don't spend as much time fi.xing errors. That system should now go through user- 
initiated impro\ements while the rest of the functions of the Flight Acti\ity 
Module arc added. 

3. Potential Problems and Benefits 

This section will highlight some of the potential problems and pitfalls that 
must be o\'crcome if OASIS is to be successfully de\elopcd and implemcnicd. 
Some of these issues have been previously mentioned, but they are important 
enough to warrant additional and separate discussion. 
a. Audit Trail and Signature Requirements 
The requirement for an audit trail could be a potential problem. 
Signatures arc required at \ arious points in the use and repair of aircraft. A pilot 
must sign for the aircraft, an inspector must sign that he has completed the in¬ 
spection in accordance with applicable instruction, and only designated personnel 
(typically MCCs) arc authorized to release an aircraft to a pilot as safe to fly. 
Pro\ision must be made for obtaining these signatures, or some other was for 
these "special c\cnts" to be marked must be found. A simple wa\ woukl be to 
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issue passwords to those authorized to sign a form. The system would ask for the 
password anytime someone attempted to complete that block. Each person's 
password would cause their name to appear in that space. Doubters would ask 
what is to prevent an unauthorized person from using another's password. The 
answer is nothing. However, aviation maintenance has always relied on the idea 
of special trust and confidence when granting the authority to individuals to cer¬ 
tify certain events with their signature. That same special trust and confidence 
would apply to the issuance of passwords. The basic elements of any good pass¬ 
word security system would ha\e to be applied, but not in such a way as to 
undermine that special trust and confidence that is so essential to effective avi¬ 
ation maintenance. For those who remain unconvinced, absolute security can be 
purchased, but at a price. Signature recognition and \erification dc\ices arc a 
possible solution to this problem, in that only with a signature that the system 
recognizes as appropriate for that event would the e\ ent show as completed in the 
system. It may be impossible to totally eliminate paper from the aircraft flying 
and maintaining cycle, but it can certainly be reduced. 
b. Availability of Experts 

For areas where ESs arc appropriate, a potential problem is the dif¬ 
ficulty of convincing upper management to let go of their expert for the time it 
will take to build the system. Inevitably, the expert you need is the one in highest 
demand [Ref. 58; p 200.]. This hesitancy must be o\ercome by cither 1) con¬ 
vincing upper management that the long term gain far outweighs the short term 
pain, or 2) getting upper management's bosses to con\incc them. Another, less 
optimum solution is to develop the expert system with limited access to the 
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expert(s). This would increase the number of iterations required, and unneces¬ 
sarily prolong development. 

c. Prototype Transition 

Another issue that must be addressed is how and when prototypes, 
or even fully developed systems (expert or others) built at the Na\ al Postgraduate 
School should transition from NPS to full fledged fleet system support. A second 
part of this issue is what activity in the information systems hierarchy of the 
Naxy is going to take over the support of those systems. Quantity and quality 
of accompanying documentation will need to be addressed. In other words, just 
because the system is developed at NPS does not relie\e NPS of satisfying the 
same requirements a commercial contractor would have to meet in fulfilling a 
contract for the system. (A more compelling reason for turning o\er a top notch 
system is the need for NPS students and faculty to practice what is being 
preached in the information systems curriculum at NPS.) This problem would 
be effecti\ely answered if NAMO does in fact take on CDA responsibilities for 
OASIS. Then, NPS-de\eloped applications would ha\e to meet the same re¬ 
quirements as an application sent to NAMO by an OMA. 

d. Procedure Correction 

Aviation maintenance may benefit from just the process of de\ eloping 
OASIS. We may find, by going through the iterative prototyping process with 
the end-users, that the way we arc doing business now has some basic fiaws. As 
Dcming [Ref. 59: pp. 9-10] and others have emphasized, automating a flawed 
process merely allows the fiaws to manifest themsehes faster once the system is 
in operation. This is not to imply that the maintenance process is fiawed and 
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needs to be evaluated. That process is in fact being constantly evaluated under 
the most demanding conditions, namely, daily flight operations. However, if we 
have accepted faulty procedures as the way some things must be done, attempting 
to automate those procedures in the literal and inflexible realm of computerized 
information systems may require that we finally change and maybe e\en stream¬ 
line those procedures. 

E. SUMMARY 

In summary, strategic planning for OMAs must precede strategic information 
systems planning. Those strategic information plans arc then translated into 
functional requirements. Finally an information system that, through this top- 
down process, meets the information needs of the organization, is planned, de- 
\eloped and implemented. Information engineering pro\ides an organized and 
formal method to perform the top-down information analysis necessary to de¬ 
velop a flexible and responsi\e information system. 

NALCOMIS, dc\eloped using the traditional problem soKing approach to 
information systems dc\elopmcnt. attempted to satisfy all the requirements in one 
system developed all at one time. For whatever reason, loss of funding, taking 
too long, or too many changes to the specific requirements, it has not been fielded 
for the OMAs. 

Contrasted with the traditional problem solving approach is that of iterative 
prototyping. This maintains continuous end-user involvement, and coupled with 
information engineering, has the potential to deliver, in a start-small-and-grow 
fashion, the tools OMA managers need to effectively apply their resources to ac¬ 
complishing CNO readiness and safety goals. 
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The preliminary module descriptions and implementation plan for OASIS has 
been presented. The preliminary plan recommends developing first those mod¬ 
ules that will have the greatest impact in terms of both visibility and usefulness. 
Finally, the potential pitfalls of an audit trail, signature requirements, expert 
availability, prototype transition, post deployment software support were high¬ 
lighted so that they can be avoided. 
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V. RECOMMENDATIONS, FURTHER RESEARCH, AND 

CONCLUSIONS 


A. RECOMMENDATIONS 

Even though this entire proposal is a recommendation of how to fill the au¬ 
tomated information management void at OMAs, there are still a few recomm¬ 
endations that will help focus the effort of those that follow. The first is that 
since we have within the Naxy the resources to develop OASIS, it should be de¬ 
veloped within the Navy. We have the people with the knowledge of aviation 
maintenance. We have a growing number of people with information systems 
knowledge. Furthermore, advancing technology is providing us with the hard¬ 
ware and software advances that make developing OASIS not only imperative, 
but, relative to 15 years ago, easy. 

The second recommendation is not original. It is something that information 
systems developers have learned with painful slowness. Involve the users. This 
means more than asking them what they want. It means getting them involved 
on day one and keeping them involved throughout the life of the system. As 
discussed, the most effective way to do that is through iterative prototyping. 
Therefore, do not waste any time fielding a prototype and using iterative proto¬ 
typing to keep the users involved. 

The third recommendation derives from the fact that the users of OASIS are 
not those at the IMAs. not those in supply, not those at higher level commands, 
but the maintainers at the OMAs. Accordingly, the requirements that determine 
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the functions OASIS performs, and the order and manner in which those func¬ 
tions are developed must come from the OMA maintenance professionals. Do 
not let OASIS be driven by the reporting requirements of higher authority or by 
the interface requirements of any other system. Those are all only small parts of 
OASIS. OASIS is for "the guys in the trenches." 

The fourth recommendation is that once aviation maintenance officers have 
been selected to attend the Naval Postgraduate School they should be contacted 
and briefed about the OASIS project and the potential for them to get an early 
start on their thesis by working on some part of OASIS. This can be best ac¬ 
complished through liaison between the OASIS developers and the a\iation 
maintenance officer detailer. This is not to suggest excluding anyone else from 
working on a part of OASIS, only to suggest that the a\'iation maintenance offi¬ 
cer community is small enough that marketing O.^SIS as thesis material is man¬ 
ageable. The student will benefit from knowing the topic of his her thesis and 
ha\ ing a ready topic for class projects and papers. The OASIS project will ben¬ 
efit from ha\ing people work on the project who do not ha\c to learn aircraft 
maintenance in the Na\'y. OASIS will also benefit from keeping academia in- 
\ol\ cd and thereby ensuring that the 'leading edge" of information systems tech¬ 
nology is applied to OASIS. 

B. AREAS FOR FURTHER RESEARCH 

This section addresses several areas that warrant further research. Each 
module is itself at least one project, and in most cases se\cral. that will need fur¬ 
ther research. Throughout this thesis, areas were pointed out that wtiuld need 
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additional study or effort. Those presented here are in addition to those already 
discussed, or are important enough to repeat. 

1. OMA Information Resource Management 

One of the alternatives to a standardized system such as OASIS is for 
each OMA to "do its own thing" with respect to information management. One 
argument in fa\’or of such an approach is that in spite of the NAMP standard, 
every OMA is a unique organization with its own style of doing things. Another 
is that by pushing a standard system we would be removing some of each CO's 
leeway in managing his OMA. On the other hand, the question of whether 
OMAs have or will ever have enough knowledge of information systems to do 
their own planning needs to be answered. Also important is the question of 
whether OMAs should be doing their own IRM planning and IS de\clopment. 
Further study into how IRM should fit within an OMA's management could 
possibly resohe these questions. The points of \'iew on these issues will range 
from the OMAs, who are tired of waiting, to Operational Commanders (who 
would probably say an OMA is there to fight, not build computer systems.). 

2. Evaluation criteria. 

To avoid falling into the trap of pouring more and more resources into a 
project that has already failed, some criteria to measure the success of OASIS 
should be decided upon at the outset. Because our real customers are the end- 
users in the OMAs around the world, their satisfaction should be the primary 
measure of success. However, being within budget and on schedule are also im¬ 
portant criteria. How to measure the chosen criteria should be an early decision 
so that tracking of them can start immediately. Limits should be established be- 
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yond which specific action is taken, e.g., at ten percent late the project is killed. 
What these criteria should be, and what limits should be established falls in the 
field of software engineering, and is certainly an area for further study. 

3. Knowledge Acquisition 

There are more than one type of aircraft in the Navy. Each has its own 
maintenance experts, and even among those experts there will be differences of 
opinion (and heuristics) about the way to solve a particular problem. Which of 
these experts should become the expert for an ES? Who decides who the expert 
is? Should there be more than one expert consulted while building an ES? Once 
chosen, will "their" ES be accepted by the other experts who were not chosen, and 
thus by the fleet? Can the experts, already in short supply, be made available for 
the time it takes to build the ES? How long will it take to acquire the knowledge 
of the expert(s)? These are all questions that must be answered for an ES to be 
developed. Finding the answers is itself a topic of thesis proportions, and worthy 
of further study. 

4. Data collection 

The user interface of OASIS must be studied. There are a wide v ariety 
of styles available. Some people prefer typing while others prefer using a mouse 
or track ball. Which will gain more user acceptance, or should both be offered? 
Should the video screens for data collection look exactly like the paper forms in 
use now, or should the data be collected by having the user respond to a scries 
of questions. Will the answers be typed in by the user, or selected from a list? 
Will a paper copy be required? What backup method will be used? How exten¬ 
sive and sophisticated should the security system be? How manv' data collection 
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points should there be (a subject for queuing theory) to satisfy the peaks and 
troughs of data entry, e.g., when ten aircrew want to fill in their flight data? Will 
the aircrew even have to fill it in anymore? Similar surges in data entry can be 
expected near shift changes and meal times as maintenance personnel try to 
complete their "paperwork." Since the user interface is in reality the most visible 
part of the system to the user, extensive study should be done to determine the 
optimum mix of available options. 

5. Implementation and Post Deployment Software Support 

Although mentioned earlier, this issue is important enough to be ad¬ 
dressed specifically. The exact method of implementation for OASIS needs to 
be studied. 0\er 400 OMAs will eventually benefit from OASIS (or a similar 
system). They can not all be a prototype site. Should use of OASIS be manda¬ 
tory or optional? What is the best method of implementation to ensure its effec¬ 
tive use? User in\'ol\'cment can only go so far with so di\ersc and disbursed a 
group of end-users. 

Current IS assets at OMAs range from \cry basic combinations of hard¬ 
ware and software to ones that are very sophisticated. An analysis of the ex¬ 
pected hardware and software requirements for OASIS must be performed. Then 
those requirements must be compared to what OMAs already have. Finally, an 
acquisition plan must be developed to ensure that all OMAs haxe the necessary 
hardware and software to implement OASIS before OASIS is available to them. 
Considering the budget process in DOD, this plan must be developed early in the 
OASIS de\elopment in order to ha\e the funding appro\ed by the time O.-XSIS 
is ready for implementation. 
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The point at which an information system is delivered to a customer is 
when the major part of the work on that system begins. The system must be 
maintained, changes in the customer's procedures must be incorporated, and er¬ 
rors that are found after delivery must be fixed. If a system takes one year to 
develop and deliver, and it is expected to be in use for nine additional years, then 
ninety percent of its life is post-delivery. Hardware is not normally the problem; 
software is. How OASIS will be supported needs to be determined. Aliernati\es 
should be identified, evaluated, and finally a decision must be made early enough 
in the development so that the support can be in place and ready when O.^SIS 
is deployed. This will mean keeping the PDSS acti\ ity (or acti\ities) as in\'oKed 
as the end-users, if not more so, throughout the de\elopment. With respect to 
expert systems, who will maintain the knowledge base? Will we ha\e to dedicate 
an expert to it, or can experts be consulted as needed by a knowledge engineer? 
W'hen changes have been made, who will authorize distributing them to the fleet, 
and how will it be done? These issues must all be resohed before OASIS is ready 
to be implemented, and are ideal candidates for further study. 

6. OASIS at AMO School 

The Na\y's school for A\iation Maintenance Officers could play a role 
in the development and support of O.ASIS. As the new maintenance officers go 
through this school they could learn how O.ASIS works, and not ha\c to learn 
by trial and error once at an OMA. Additionally, since the school is staffed and 
taught by fleet experienced maintenance personnel, their ideas and suggestions 
would be in\aluable to both the initial development and the post deployment 
support. They, unlike their peers still at OM.As, may be able to devote time to 
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such a project without detracting from their performance. Encouraging them to 
constructively critique OASIS and become actively involved in the system could 
help overcome their reluctance, while still at an OMA, to 1) put themselves on 
report by advertising problems, and 2) take the time from their hectic crisis- 
ridden daily jobs to submit changes to the systems that are supposed to help 
them. 

C. CONCLUSIONS 

The strategic goal of an Organizational Maintenance Activity is to achieve 
and maintain Chief of Na\al Operations standards of readiness and safety. 
Achiexing that goal requires planning the effectixe acquisition and use of re¬ 
sources. One of the resources is information. Not onl}’ is information a resource, 
but also timely, accurate and relexant information is vital to effectixe manage¬ 
ment of the other resources, specifically aircraft, people, equipment and money. 

OMAs are tasked xvith managing billions of dollars of phxsical assets, hun¬ 
dreds of people and their training, and tremendous inxentories of parts, supplies, 
publications and equipment xvith no modern management tools to help. The need 
to manage the information resources of aviation maintenance managers was 
formally recognized when NALCOMIS xvas conceived. Todax . the onlx question 
remaining is the specific information system that xvill provide the modern tools, 
and when it will actually be implemented at OMAs. 

Information systems technology has made phenomenal advances in the past 
15 years. We in aviation maintenance must capitalize on advances in structured 
analysis methods, information engineering techniques and artificial intelligence 
tools. Failure to do so would be a tragedy. 
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Much work has gone into the assorted information systems used at different 
a\ iation maintenance levels and activities. Several of these systems can pro\ ide 
\'aluable information to OMAs and should be tasked with doing so in a form that 
can be used by OASIS. 

Undertaking to dc\'elop an information system complex enough to support 
the information needs of Organizational Maintenance Acti\itics is an ambitious 
objective. It has been tried before. However, by reducing the project to modules 
of manageable size, and applying the concept of evolutionary prototyping. OMAs 
will finally reap some benefit. As more modules are de\elopcd, the full impact 
of managing information effectively will be realized. We must fill the \oid 
intelligently, but QUICKLY. OASIS is the initial step. 
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APPENDIX A. ACRONYMS AND ABBREVIATIONS 


AEMS 

AMMRL 

AMO 

AMRR 

ARS 

ASETS 

ATSS II 

AV-3M 

BOR 

CANDES 

CDA 

CD-ROM 

CIMP 

CNO 

CO 

CONUS 

DD/DS 

DOD 

DON 

DSS 

ES 

FRS 

IE 

IMA 

IMRE 

IRSTRATPLAN 


Aircraft Engine Management System 

Aircraft Maintenance Material Readiness List 

Assistant Maintenanace Officer 

Aircraft Material Readiness Report 

Aerial Refueling Stores 

Aviation Squadron Enlisted Training System 

Aviation Training Support System—Phase II 

A\ iation Maintenance and Material Management 

Budget OPTAR Report 

Computer Aided NAVFLIR Data Entry System 

Central Design Activity 

Compact Disk-Read Only Memory 

Component Information Management Plan 

Chief of Naval Operations 

Commanding Officer 

Continental United States 

Data Dictionary Directory System 

Department of Defense 

Department of the Na\y 

Decision Support System 

Expert System 

Fleet Readiness Squadron 

Information Engineering 

Intermediate Maintenance Acti\ ity 

Individual Material Readiness List 

Department of the Navy (DON) Strategic Plan for Man¬ 
aging Information and Related Resources 
(IRSTRATPLAN) 
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IS 

LAN 

LCM 

MAP 

MC 

MCC 

MDCS 

MDS 

MIS 

MO 

MPA 

MMCO 

MRS 

NADEP 

NADIS 

NALDA 

iNAMO 

NAMP 

NAMSO 

NALCOMIS 


Information System 

Local Area Network 

Life Cycle Management 

Maintenance Action Form 

Maintenance Control 

Maintenance Control Chief 

Maintenance Data Collection System 

Maintenance Data System 

Management Information System 

Maintenance Officer 

Manpower Authorization 

Maintenance Material Control Officer 

Management Reporting System 

Na\'al Aviation Depot 

Na\'al Aviation Depot Information System 

Naval A\iation Logistics Data Anal\sis 

Na\'al Aviation Maintenance Office 

Naval Aviation Maintenance Program 

Naval Aviation Maintenance Support Office 

Naval Aviation Logistics Command Management Infor¬ 
mation System 


NALCOiMPT 

NAVAIR 

NAVFLIR 

NAVMASSO 


Navy Comptroller 
Naval Air Systems Command 
Naval Flight Information Record 
Navy Management Systems Support Office 
NAVSEALOGCEN Naval Sea Logisitics Center 
NAVSO Navy Staff Office 

NAVSL'P Naval Supply Systems Command 

NMPC Naval Military Personnel Command 

NOAP Nav al Oil Analysis Program 

NRMM NALCOMIS Rcpairables Management Module 
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OASIS 

OPTAR 

OPSO 

OMA 

PMA 

PIMS 

POE 

RFI 

ROMC 

SAF 

SEGA 

SERMIS 

SFO/EDL 

SQMD 

SSC 

SUADPS 

TD 

TIVIS 

TPS 

TYCOM 

UADPS 

VALSPECS 

VAMOSC 

VIDS 

VIDS/MAF 

XCON 

XO 


Organizational Activity Standard Information System 

Operating Target 

Operations Officer 

Organizational Maintenance Activity 

Program Manager Air 

Planned Maintenance System 

Planned Operating Environment 

Ready For Issue 

Representations, Operations, Memory aids. Control mech¬ 
anisms 

Support Action Form 

Support Equipment Controlling Acti\ity 

Support Equipment Resources Management Information 
System 

Summary Filled Order Expenditure Difference Listing 
Squadron Manning Document 
Supply Support Center 

Shipboard Uniform Automated Data Processing System 

Technical Directive 

Type, Model, Series 

Transaction Processing System 

Type Commander 

Uniform Automated Data Processing S\stem 
Validation Specifications 

Visibility and Management of Operating and Support 
Costs 

Visual Information Display System 

Visual Information Display System Maintenance Action 
Form 

The Expert Configurer (used by Digital Equipment Corp.) 
Executi\e Officer 
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